Governing AI agents: the Blueprint Alliance whitepaper, summarized

The Blueprint Alliance's whitepaper, Governing Agentic Execution (PDF), is an open, multi-vendor reference architecture for securing AI agents inside large organizations. Its central claim is simple: an agent is a security principal in its own right. It is not a script and it is not a borrowed human login, so it needs the same identity, access, monitoring and offboarding controls we already apply to employees and service accounts. The paper organizes those controls around four questions: Where are my agents? What can they do? What are they doing? How do I respond?

It is written for CISOs, CIOs, CTOs and security architects. But if you connect MCP servers, skills or plugins to work systems, you will recognize every problem it describes. This post summarizes each section and then lists the takeaways I think matter most.

Why the paper exists#

The paper opens with a Gartner prediction: by 2028 the average global Fortune 500 company will run more than 150,000 agents, up from fewer than 15 in 2025. It also says only 13% of organizations believe they have the right agent governance in place.

The authors call the result an identity, security and governance gap: shadow agents multiply, credentials get inherited across trust boundaries, and execution goes uncontained. Old controls don't fit because agents break the split between human identities (SSO, MFA) and machine identities (service accounts, API keys). The paper contrasts the two:

The conclusion is that security can't be bolted on at the model or network layer. It has to live in an agentic control plane that governs visibility, connectivity and execution continuously.

The five questions boards are asking#

The paper lists five questions that security and compliance committees keep raising:

1. Where are our AI agents, and who owns them?
2. How do we restrict what agents can execute and keep them on task?
3. Can we audit and explain autonomous decisions after the fact?
4. What is our data exposure and third-party risk across the agent supply chain?
5. Do we have a verified kill switch and rollback plan if an agent goes rogue?

These map onto the four pillars: discovery and identity answer question 1, access management answers 2, runtime monitoring answers 3 and 4, and containment answers 5.

The authors stress these are a diagnostic, not a checklist: a read-only assistant doesn't need the containment controls of an agent that moves money.

Six principles#

Everything in the architecture rests on six principles that extend zero trust to agents:

• Every hosted agent is a distinct identity. Agents are provisioned, authenticated and deprovisioned like employees, pilots included.
• Access is scoped to the task, not standing. The paper admits fully task-scoped grants are aspirational; in practice you pair short-lived grants with a baseline set of permissions.
• Delegation is traceable end to end. When a human delegates to an agent and that agent spawns a sub-agent, every action should trace back to whoever authorized it. Again, the paper is candid that multi-hop delegation is a target that today's tooling only partly supports.
• Runtime is isolated and monitored, not just provisioned. What an agent was granted at setup is necessary but not sufficient. You also need behavioral baselines from real runs.
• Containment is instant and reversible. Every agent, from any vendor, needs a targeted kill switch that can suspend, quarantine or terminate it, and a clear way back.
• Governance adapts at the speed of AI. Static permission ceilings are combined with dynamic, context-aware scoping.

The four pillars#

The reference architecture arranges its components under the four questions, on top of a shared telemetry and risk-signal layer.

Pillar 1: Where are my agents?#

You can't govern what you can't see, so the first pillar is discovery, posture and identity.

Discovery covers agents your teams build, agents imported from vendors and registries, and shadow AI. For imported agents, the paper suggests asking three questions: who built it (first-party, SaaS, local or orchestration platform), who it serves (employees, businesses, consumers or an individual), and how it arrived (agent gateway, vendor catalog, or MCP and skill registry). Shadow AI discovery spans cloud, network egress, endpoints, browsers, OT hardware and even mail and calendar traffic, within privacy and employment rules.

One idea here is worth highlighting: the governed execution path as a detection surface. If every sanctioned agent runs through a central control plane, then any agentic process running outside it is a shadow AI signal by definition. You don't need a separate detection rule for each environment.

Agent security posture management (AIASPM) evaluates what discovery finds: vulnerabilities, signed provenance for code and model weights, misconfigurations such as hardcoded credentials, and adversarial testing in disposable sandboxes. It also includes tool and skill supply-chain scanning, which inspects MCP tool schemas and skills, including entries pulled from public registries, for hidden code and unauthorized egress before they are registered.

The Agent Directory is where a discovered agent becomes a governed one. Each hosted agent gets a verified profile, a cryptographic identity, an accountable owner and recorded relationships. The paper defines classes from autonomous and on-behalf-of agents to orchestrators, sub-agents and guardian security agents, which need stricter attestation because they hold containment powers.

Two practical notes stand out. Registration should be lightweight, or teams will route around it with shared human credentials. And sub-agents must run inside isolated execution boundaries that structurally enforce their inherited scope, because task boundaries enforced inside the model can fail. Across organizations, identity travels via standards such as OAuth Token Exchange and HTTP Message Signatures.

Pillar 2: What can they do?#

This pillar defines what a registered agent may read, write or execute. Policies layer from coarse-grained roles to fine-grained rules tied to data classification, relationship-based access (who spawned this agent, who it acts for), intent-based checks on the agent's plan, time-bound grants, and hard guardrails that override the agent's reasoning entirely.

Two rules are worth remembering:

• A sub-agent's effective permissions are the intersection of its own entitlements and those of whoever delegated to it. This prevents confused-deputy escalation. Policy should also cap how wide and deep delegation can fan out.
• Expiry alone is weak. Auto-approved, auto-expiring grants add little on their own; pair them with anomaly detection.

Governance brings familiar identity practices to agents: human review above set thresholds (the paper's example is a purchase over $1,000, even if the agent has permission), continuous access reviews, separation of duties (no agent both creates and approves a payment), and joiner-mover-leaver processes for owner changes and model upgrades.

Pillar 3: What are they doing?#

Identity and policy mean little without runtime enforcement. The paper describes five gateway types, each owning a different control point:

• AI/LLM gateway for model API traffic, token counts and rate limits.
• MCP gateway for tool and context traffic to MCP servers.
• Security gateway for inline inspection: prompt injection, jailbreaks, malicious payloads and outbound redaction.
• Agent gateway that binds identity to every request, maintains the tool and MCP registry agents draw from, and injects short-lived credentials at call time so agents never hold standing API keys.
• API gateway that still performs its own final authorization on every call, rather than trusting that upstream gateways caught everything.

Monitoring adds sandboxing, anomaly detection, prompt-injection scanning, output DLP, tracing of sub-agent calls, cost tracking for runaway loops, and pause points for human sign-off.

The paper then goes a step further with continuous intent and alignment enforcement. Initial policy decides what an agent may access; this layer checks whether its behavior still matches the delegated task as it runs. It compares planned tool calls with actual ones to catch drift, injection-driven detours and confused-deputy behavior, and records why each material action was allowed, changed or blocked.

Purpose-aware data security applies controls at the moment data is used, not only when it is accessed. Classification tells you what data is; purpose-aware controls decide whether this particular summary, export or message to a third-party agent is appropriate for the task at hand.

Pillar 4: How do I respond?#

Containment should be proportional. The paper prefers the least disruptive response that works, such as throttling, then token or session revocation, network quarantine and environment suspension, with process or platform termination as a last resort. Termination destroys in-memory forensic data, so suspension is preferred.

One warning stands out: a kill switch only works if the runtime can pause one agent without collateral damage. Without that support, API-driven containment only looks like control.

The paper also insists on the second half of the loop: access recovery. A contained agent returns only after re-attestation against a known-good baseline, staged re-enrollment (read before write, sandbox before production), a documented root cause, and a closed audit record linking the incident from start to finish.

The cross-cutting layer#

Under all four pillars sit two shared components. Execution context and risk signals correlate individually low-risk events into toxic combinations (for example, a prompt injection followed by an attempt to pull financial data) and trigger enforcement automatically, using open standards such as the Shared Signals Framework and CAEP. Telemetry and logging, normalized with OCSF, form the base layer. Crucially, telemetry should be captured at the execution boundary rather than self-reported by the agent, so a compromised agent can't edit its own record.

Making it real: the operating model#

The paper argues that an architecture without an operating model becomes shelfware within a year. It frames this section around global system integrators, though it says internal teams or managed providers can do the same work.

The most useful part is the suggested ownership split: security engineering owns gateways and monitoring, IAM owns the directory and policies, the SOC owns response, and platform engineering owns sandboxes and runtimes. It also covers risk tiering, regulatory mapping and sector playbooks.

Where to start#

The paper closes with the sequence it says Alliance member deployments actually followed:

1. Stand up unified logging and telemetry first. Everything else depends on it.
2. Start with discovery, not policy. Most teams find more agents than they expected.
3. Register before you restrict. A policy on an unregistered agent governs nothing.
4. Layer authorization. Fine-grained and relationship-based controls must exist before intent-based policies can narrow them.
5. Instrument runtime before automating response. Automated containment on noisy data produces false positives that erode trust.
6. Pressure-test the kill switch. As the paper puts it, "a kill switch you've never tested is a hypothesis, not a control."
7. Treat governance as continuous, on the same cadence as human identity governance.

Key takeaways#

Agents are identities, so manage them like identities. The most useful shift in the paper is moving agent security out of "AI safety" and into identity and access management, a discipline with mature processes for onboarding, reviews and offboarding.

Don't let the model enforce its own boundaries. Sub-agent scope, isolation and guardrails are enforced structurally, outside the model's reasoning. Prompts are not a security boundary.

MCP servers and skill registries are supply chain. The paper treats every tool schema or skill pulled from a registry as untrusted input that needs scanning before use, and calls out registries as an injection vector.

Get credentials out of the agent's hands. Gateways that inject short-lived credentials at call time remove the standing API keys that make a compromised agent so damaging.

Check behavior, not just permissions. Comparing an agent's plan with its actual actions, and applying data controls at the moment of use, closes the gap between authorized and safe.

Plan the way back. Proportional containment plus a documented recovery path makes it realistic to pull the switch without fearing an outage.

Match controls to risk. Heavy controls on a read-only assistant slow adoption and push people toward shadow AI, which is the problem the paper starts with.

What the paper doesn't settle yet#

It is a reference architecture, not a standard. Several key pieces, including task-scoped access, multi-hop delegation and automated recovery, are labeled aspirational. The founding members aren't named in the PDF, and the interoperability results it promises haven't been published yet. Its five example scenarios are composites, not case studies. And it is long on taxonomy and short on concrete policy examples or formats. Read it as a shared vocabulary and a map of the controls to aim for, not as a spec you can certify against today.

What this means if you use MCP servers and plugins#

You don't need an enterprise control plane to apply the core ideas. Know which MCP servers and plugins are connected and who owns each one. Prefer OAuth with narrow scopes over personal API keys in config files. Review tool definitions before trusting a server you found in a registry. Require confirmation for write actions, especially when an agent also reads untrusted content like email or web pages. And disconnect what you no longer use. Our plugin and MCP security checklist covers these steps in detail, and the MCP directory shows which servers come from the vendor that runs the service.