RAISE
Responsible AI Governance and System Engineering
Layers Controls Pillars Gates Assessment Book Contact
RAISE Framework

Govern the paths your agent finds on its own.

Blocking a tool is not the same as preventing an outcome. RAISE puts governance in the architecture, in layers, so that when an agent finds another route, finding it does not mean it gets to take it.

See the layers Score your readiness
Pillars
8
Lifecycle gates
6
Operational controls
4
Built for
CISOs and platform teams
Thursday afternoon. A laptop. A changelog.
What one disallowed tool actually did
1
Give the agent a goal
Read the commits since the last tag and write CHANGELOG.md.
2
Block the obvious path
disallowed-tools: [Write]. The skill cannot create files.
3
Watch it reason
I'll delegate this to a fork so the verbose git log work stays out of my context (and since Write is disallowed for this direct invocation).
4
22 seconds later
CHANGELOG.md exists. The subagent never inherited the restriction.
Nothing broke. Nothing was jailbroken. The boundary just did not travel as far as the work did.

Nothing was broken. That is the point.

The agent behaved exactly as designed. It had a goal, hit a constraint, and found another valid path. That is the behavior you want when an API fails or a service is down. It is also what makes a single guardrail insufficient.

Now scale it. Give the same pattern access to production APIs, cloud infrastructure, customer data, release pipelines, financial systems, or other agents. You do not need a science fiction scenario. You need a capable agent, meaningful permissions, and one route your controls did not cover.

You cannot just ask, "Did I block the Write tool?" You have to ask, "Did I prevent this system from modifying a file, regardless of which path it chooses?"

Those are two very different questions. RAISE exists to help you answer the second one.

Guardrails have to work in layers.

Each layer is another chance to stop an action, limit what the agent can reach, or at minimum see what happened. Select a layer to see what it enforces and what it cannot.

Four operational controls

The capabilities that make governance executable in production. Every pillar and every gate below maps back to one of these.

Inventory

Know every agent that exists, who owns it, what it can reach, and who it can delegate to. If you cannot list it, you cannot govern it.

Monitor

Trace tool calls, the delegation chain, policy decisions, MCP requests, and the identity behind each one. The output can look fine when the path was not.

Guardrails

Enforce policy at runtime, at the agent, outside the agent, at the MCP server, and at the network. One missed rule should never be your whole security model.

Recover

Contain the run, revoke the credential, reverse the action where you can, and learn from the trace. A recovery path is part of the design, not the incident.

The eight pillars

Tool-agnostic by design. Open a pillar for the practices and the example controls behind it.

Six lifecycle gates

Governance shows up as go or no-go decisions with an owner and evidence. Not a paper review. Select a gate.

What you confirm
    Evidence you produce
      Who signs

        Score your readiness

        Rate each pillar from one to five. The profile updates as you go. Print it and take it into your next architecture review.

        Overall readiness0%
        1 = starting out. 3 = partial, mostly manual. 5 = enforced at runtime with evidence.
        Pillar profile
        Rate a few pillars to see where the gaps are.
        Cover of AI Agent Governance: Operational Patterns for Security, Oversight, and Control, by Kesha Williams

        The book behind the framework

        Follow one MCP-connected agent from first deployment to a multi-agent system coordinated over A2A, and watch the governance problems grow with it.

        • Behavioral drift and unauthorized tool access
        • Unsafe delegation and permission boundaries that do not travel
        • Domino failures across agents
        • Identity, observability, and the audit trail
        • Recovery when a run goes wrong

        A GitHub repository and an Agent Governance Console sandbox let you build alongside the chapters. It is early release, so the book is still evolving, and feedback from people running agents in production shapes what ships next.

        Read the early release

        Resources

        Templates you can drop into your next sprint. Contact us for an access code.

        RAISE one-pager
        The pillars, gates, and controls on a single page for executives.
        Agent inventory template
        Owner, identity, tools, delegation targets, and readiness score per agent.
        Incident response checklist
        Contain the run, revoke access, reverse actions, and capture the trace.

        Bring RAISE to your teams

        Want help applying the framework to the agents you are already running? Tell me what you are trying to govern.

        Prefer email? hello@keysoft.tech