AI agents are now in production across healthcare, financial services, and critical SaaS systems. They mutate data, trigger workflows, and call external APIs on behalf of real users. These are autonomous actors, not the read-only recommendation engines that security teams already know how to govern. The business is shipping them, and saying no won’t pause that. The CISO question is no longer whether to allow agents into production. It’s how to say yes safely, fast enough that security isn’t the reason the business can’t ship.
The honest answer is that traditional enterprise security models don’t survive contact with this workload. Governance-as-logging assembles evidence after the breach. Governance-as-spreadsheet drifts the moment code ships. Governance-as-policy-PDF answers an auditor’s question about intent, not the runtime question of what an agent actually did at 03:14 on a Tuesday. None of these are governance. They are documentation. And building bespoke security infrastructure to close the gap is the same mistake in engineering form: months of plumbing while the actual governance gap stays open.
Governance is a runtime contract enforced at the exact millisecond of every tool call, paired with an immutable audit trail that an auditor can replay end-to-end. Every agent action must be attributable, policy-governed, immutably audit-replayable, and revocable across user, agent, tenant, and task. Enforced at runtime, provable after the fact.
What follows is a CISO-grade rubric organized around the four concerns CISOs surface in the field, with the six runtime capabilities that address them. Hand it to your AI/ML team. Hand it to the security architects and IAM leads pulled into the project. Both audiences should be able to verify against it before any agent reaches production.
TL;DR
A CISO-grade rubric for AI agent governance organizes around the four concerns every CISO surfaces in the field. The 6 capabilities that address them sit beneath each:
1. Identity and attribution: the service account problem.
- Capability 1: Agent and tool registry under version control
- Capability 2: Delegated agent authorization with scoped, just-in-time credentials
2. Active prevention at the tool call: saying yes safely.
- Capability 3: Centralized policy enforcement at runtime
- Capability 4: Action-layer guardrails (parameter validation, rate limits, output filtering, prompt injection interception, step-up authorization for high-impact actions)
3. Observability your SIEM can use: after the fact.
- Capability 5: Immutable, replayable audit trail
4. Continuous audit-readiness: the verification rubric itself.
- Capability 6: Compliance attestation at the agent and action layer
No patchwork of SIEMs, policy engines, GRC platforms, identity providers, or MCP gateways answers all four concerns end-to-end. A unified MCP runtime does.
Mapping AI agent governance to NIST, ISO/IEC 42001, and the EU AI Act
The policy layer of enterprise AI governance is defined by a small set of converging international frameworks: ISO/IEC 42001, the NIST AI Risk Management Framework, ISO/IEC 42005, the EU AI Act, and the CSA/NIST Agentic Profile, which extends them for autonomous systems. Technical controls need to anchor here.
ISO/IEC 42001 sets the foundational requirements for an enterprise AI Management System. It demands continuous system monitoring, strict event logging, and traceable data provenance.
The NIST AI Risk Management Framework, extended by the GenAI Profile, provides a risk operating model that emphasizes continuous testing, evaluation, verification, and validation throughout the agent lifecycle.
ISO/IEC 42005 builds on these by mandating rigorous AI system impact assessments. You’ll need documented, immutable evidence of risk treatments and architectural safeguards.
The EU AI Act is what’s actually driving urgency. Its phased timeline doesn’t just turn best practices into legally binding requirements. It turns the gap between policy and runtime into a legal liability that the security team is responsible for.
Prohibited practices and AI literacy obligations became applicable on February 2, 2025. Strict obligations for General Purpose AI providers took effect on August 2, 2025, requiring detailed technical documentation and systemic risk monitoring. By August 2, 2026, the broad applicability phase requires that every high-risk AI system implement automatic, immutable logging and strict human oversight.
These are not deadlines on the security team’s roadmap. They are legal exposure that attaches whenever an agent in a regulated workload acts without governance evidence the runtime can produce on demand. “We’re planning to address this” is not a defensible position when an auditor asks why the agent that processed yesterday’s PHI access can’t be replayed.
The Cloud Security Alliance and NIST Agentic Profile bridge the gap between broad regulatory mandates and technical implementation. This profile explicitly extends the NIST AI RMF to address threats specific to autonomous systems.
It introduces autonomy-tier classification, tool-use risk modeling, and continuous delegation-chain monitoring, giving you the vocabulary to assess multi-agent interactions.
Standards define what. A runtime defines how.
These standards are rigorous about the policy layer. They are silent about execution. NIST AI RMF tells you to monitor; it doesn’t intercept a prompt injection. ISO/IEC 42001 tells you to log; it doesn’t block an undesired API call. The EU AI Act requires human oversight; it doesn’t mandate cryptographic approval for a specific tool-call payload.
Closing the gap between legal requirement and technical reality is a runtime problem, not a documentation problem. The control point is the action layer (the moment an agent tries to call a tool), not the infrastructure boundary, the network perimeter, or a policy document. Runtime enforcement is what turns the standards into active security controls at the place the action actually happens.
Classifying AI agent autonomy tiers (1–4)
Governance strictness has to scale with agent autonomy. A structured classification gives you the vocabulary to do that.
The CSA / NIST AI RMF Agentic Profile defines a four-tier classification aligned with the operational characteristics that drive governance requirements. Data sensitivity, action reversibility, and potential legal or customer impact should dictate the maximum acceptable tier for any workload.
Agent autonomy-tier classification (CSA / NIST Agentic Profile)
| Autonomy tier | Description | Governance requirement |
|---|---|---|
| Tier 1: fully supervised | Agent generates outputs that require human approval before any action is taken. | Governance structures equivalent to non-agentic generative AI. |
| Tier 2: constrained autonomy | Agent executes pre-approved action types within a predefined scope. Actions outside that scope require human escalation. | Formal action scope documentation, approval authority delegation policies, defined escalation triggers, action-consequence mapping. |
| Tier 3: broad autonomy within boundaries | Agent operates with broad autonomy within a defined operational boundary. Bounded by hard constraints on resource access, action scope, and time horizon, and subject to continuous monitoring. | Continuous behavioral monitoring, defined response playbooks, real-time agent registries integrated with IAM. |
| Tier 4: full autonomy within constrained environment | Agent operates at full autonomy within a constrained environment, capable of spawning sub-agents, acquiring new tool capabilities, and executing long-horizon plans with minimal human interaction. | All Tier 3 requirements plus formal oversight board review at defined intervals. |
Tier 1 is the starting point for high-stakes workflows where you can’t easily reverse an action; every output is gated by human approval before it executes. Tier 2 is the practical default for most current enterprise deployments. Agents act autonomously within pre-approved scopes and escalate anything outside them. Tier 3 introduces broad autonomy within a defined operational boundary and is appropriate where continuous monitoring and well-bounded behavioral envelopes are in place. Tier 4 introduces sub-agent orchestration and long-horizon planning. It requires formal oversight board review and is rarely appropriate outside controlled research environments or specialized workloads.
Action-layer risk taxonomy for AI agents (tool calls, identity, and delegation)
Relying on generic vulnerability lists, such as the OWASP Top 10, isn’t enough to secure autonomous systems.
Prompt injections and training data poisoning are real concerns. But when you deploy agents, focus on the action layer. When an AI system can mutate data, trigger workflows, and interact with external APIs, the threat model changes.
Once an agent can act, the threat model collapses into a set of operational questions: which tool, with which parameters, on whose behalf, under which policy version, with what approval, and for how long that authority holds. The last one, time-bounded authority, is the dimension most often missed. A token issued for a session must expire when the session ends, not linger for hours or days as a residual credential that outlives the workflow that produced it. Just-in-time issuance and tight TTLs are part of the threat model, not part of the infrastructure details.
An action-layer risk taxonomy maps specific agentic threats directly to architectural mitigations in the runtime, moving security teams from theoretical vulnerabilities to deterministic system design.
Threat-to-mitigation mapping for tool calls
Action-layer threat-to-mitigation mapping
| Threat vector | Description | Primary mitigation (from 6-capability framework) |
|---|---|---|
| Tool-call hijacking | Malicious input manipulates the agent into calling a tool with malicious or manipulated parameters. | Capability 4: action-layer guardrails (parameter validation) |
| Delegated prompt injection | An agent is compromised by malicious data it retrieves from an external source, leading to undesired actions within its authorized scope. | Capability 2: delegated agent authorization (scoped credentials limit blast radius) |
| Credential exfiltration | An agent with overly broad permissions leaks or misuses sensitive credentials to which it has access. | Capability 2: delegated agent authorization (per-agent identity, rapid revocation) |
| Shadow tool execution | Developers connect unauthorized tools or external APIs to an agent without centralized security oversight. | Capability 1: agent and tool registry under version control |
| Unattributable automation | An agent executes a destructive action, but security teams cannot definitively prove which user or policy authorized it. | Capability 5: immutable, replayable audit trail |
| Context window poisoning | Sensitive information reaches the agent’s context when it shouldn’t: secrets or PII in tool outputs, retrieved data, or memory shared across user sessions. | Capability 4: action-layer guardrails (output filtering and redaction) |
Categorizing risks by tool invocation and identity lets security leaders build active defenses that intercept malicious intent before it reaches the resource server.
This taxonomy shows that defending an agentic system requires structural controls at the exact moment a tool is called. Legacy approaches that rely solely on model-level alignment or generic network firewalls don’t cut it.
Service accounts: the universal failure mode
Every CISO has been burned by shared service accounts. They break attribution. They block revocation. They’re how a single misconfigured credential ends up holding access to half the data lake six months after the engineer who provisioned it left the company. Every agent project that ships on a service account repeats that mistake faster.
The failure modes are predictable. Give the agent its own identity with broad permissions, and any user behind that agent (including an intern) can bypass their own access controls. Lock those permissions down to be safe, and the agent can’t do anything useful, which is how most agent projects stall before reaching production. Let the agent inherit the user’s full permissions instead, and one prompt injection cascades through every system that user can touch. Three patterns, all breaking least privilege the moment an agent acts on behalf of more than one person.
The fix is not better service account hygiene. It’s per-agent identity tied to the requesting user, scoped to the specific tool and action, acquired just-in-time, and revocable in isolation when that user is offboarded or compromised. This is the foundation every other governance capability rests on. The rest of the rubric assumes you’ve fixed this problem first.
The 6-capability rubric for AI agent governance at runtime
Neutralizing those risks requires an architecture that controls the full lifecycle of an agent action. Fragmented observability tools don’t get you there. You need a unified MCP runtime that addresses all four CISO concerns through six specific capabilities.
This is the rubric a CISO hands to their AI/ML team to verify before any agent is deployed to production. Skipping any capability creates a gap that an auditor or attacker will find. Arcade.dev is the reference implementation.
The 6-capability rubric, organized by CISO concern
| CISO concern | Capabilities |
|---|---|
| Identity and attribution: the service account problem | 1. Agent and tool registry under version control 2. Delegated agent authorization with scoped, just-in-time credentials |
| Active prevention at the tool call: saying yes safely | 3. Centralized policy enforcement at runtime 4. Action-layer guardrails (parameter validation, rate limits, output filtering, prompt injection interception, step-up authorization for high-impact actions) |
| Observability your SIEM can use: after the fact | 5. Immutable, replayable audit trail |
| Continuous audit-readiness: the verification rubric itself | 6. Compliance attestation at the agent and tool plane |
Identity and attribution: the service account problem
If service accounts are the universal failure mode, this concern is the resolution. The registry establishes which agents and tools exist; delegated authorization with scoped credentials binds every action to the specific user, tool, and scope that authorized it.
Capability 1: Agent and tool registry under version control
A centralized agent and tool registry under strict version control is the foundation of any governance stack. The registry ensures agents can only discover and invoke vetted, approved tools, preventing shadow servers and duplicated effort across teams.
Every agent, every tool, and every connected MCP server should appear in the registry with their owners, purposes, model versions, autonomy tiers, and approved user populations. If you can’t produce this list on demand, your governance posture is already drifting.
Capability 2: Delegated agent authorization with scoped, just-in-time credentials
Treating the agent as a distinct security principal is the architectural commitment that resolves the service account problem. That means per-agent identity, scoped credentials acquired just-in-time, and a credential scope bound to a specific user, tool, and action context. Identity answers who the agent is acting as. It does not, on its own, decide whether any particular request is safe to execute. That decision is the job of policy and enforcement, which come next.
Static API keys and shared service accounts break attribution and force you into all-or-nothing access decisions. Per-user, per-tool, just-in-time scoped tokens preserve least privilege without bottlenecking the agent. They also let security teams revoke access rapidly, isolating and ending a compromised agent’s access instantly without impacting the broader system or shared service accounts.
Active prevention at the tool call: saying yes safely
Identity is necessary but not sufficient. The CISO needs assurance that even a correctly identified action will be blocked if it falls outside policy or requires human authorization. This concern is the active defense layer between the agent’s intent and the resource server.
Capability 3: Centralized policy enforcement at runtime
Identity says what the agent’s credentials permit. Policy says what the organization permits. Different decisions, same tool call.
An agent might have valid credentials to call the trade API (Cap 2) but still be blocked by a policy that requires human approval for trades over $10K, denies trades for restricted instruments, or restricts production changes outside business hours. Centralized policy-as-code, evaluated at every tool call, keeps these business rules consistent across teams.
Each decision records the exact policy version that authorized it. Without strict version pinning, you get silent compliance breaks when authorization rules are modified or rolled back. An auditor investigating an action three months after the fact must be able to replay the exact decision matrix that authorized it.
Capability 4: Action-layer guardrails
Identity tells you who the agent is. Policy tells you whether the action is allowed. Enforcement is what actually intercepts the request and either blocks it, modifies it, escalates it to a human, or otherwise transforms it. This is the layer that catches what identity and policy don’t.
Pre-tool-call enforcement validates parameters and applies rate limits before the request reaches the resource server. Post-tool-call enforcement filters and redact outputs before they re-enter the agent’s context window. This is where threats like tool-call hijacking and context window poisoning are caught at the exact moment a tool is called.
For irreversible or high-impact actions, enforcement should escalate the request out of band for human approval. The list of actions that trigger step-up authorization includes sending external email, modifying production data, executing code, transferring money, changing permissions, deleting records, and any decision affecting employment, credit, health, or legal status. Approval thresholds scale with the agent’s autonomy tier, with stricter requirements at Tier 2 and above.
Relying on an agent to request permission in a chat interface is deeply flawed. Prompt injections can easily bypass these in-band checks. Process approvals out-of-band using standard protocols like JSON Web Signatures, cryptographically linking the human approval to the specific tool-call’s hash and context. You’re proving mathematically that a human authorized the exact payload the agent intends to send.
Observability your SIEM can use: after the fact
Even with prevention in place, incidents happen. The CISO comes in after the fact and needs an audit trail that their existing SIEM can query and replay, plus a detection layer that surfaces drift before it becomes the next incident.
Capability 5: Immutable, replayable audit trail
Governance requires tamper-proof, replayable evidence. You need immutable audit logs that support full replay of any agent interaction.
The minimum for attribution is five fields: Agent ID, User ID, Tool Call, Target System, and Timestamp. With those, you can prove who triggered which action, against which system, when. Full replay (which an auditor will ask for) requires the runtime to capture in addition to the above: Tenant, Task, Prompt Hash, Retrieved-Context References, Model Version, Policy Version, Decision, Approval, and Output Hash. All stored immutably.
This stream should follow the OpenTelemetry GenAI semantic conventions for export to an enterprise SIEM. Include key attributes, such as the operation name and requested model, to ensure interoperability.
Continuous audit-readiness: the verification rubric itself
The first three concerns address what the runtime does. This one addresses how you continuously prove it, without manual evidence assembly at audit time.
Capability 6: Compliance attestation at the agent and tool plane
Compliance attestation becomes native to the runtime. Because every action is authenticated, evaluated, and immutably logged, the system continuously generates the exact evidence required for SOC 2 Type II attestation at the agent and tool plane.
The same audit stream maps to ISO/IEC 42001 management-system controls, NIST AI RMF risk functions, ISO/IEC 42005 impact assessments, EU AI Act jurisdictional obligations, OWASP LLM Top 10 risk categories, and CSA Agentic Profile autonomy classification.
Governance requires an integrated runtime. Security treated as an afterthought in observability won’t survive a regulator’s first replay request.
Observability and SIEM integration
A runtime governance layer doesn’t sit parallel to your security stack. It extends the SIEM, IAM, and DLP investments you’ve already made. The “I already have too many tools” objection is the right one for a CISO to lead with. The answer is that the runtime is not another tool. It’s a layer that extends the ones you have into the place and enforces the policies where agents actually act. Flexible, not parallel.
Every agent action emits a structured event that follows the OpenTelemetry GenAI semantic conventions. Your security operations team queries these events in the same SIEM they already use (Datadog, Splunk, New Relic, Sumo Logic), using the same query syntax and dashboards. Identity flows from the same IdP that handles human login. Sensitive-payload detection is built on the same DLP that classifies your file shares. Nothing parallel; everything already familiar to the security team.
That distinction matters at audit time. Auditors don’t ask for a binder of policies and screenshots. They query the audit log for the exact action, time window, or policy version they are interested in. A runtime that emits OpenTelemetry GenAI events lets your security operations team answer that query in the tools they already use to query everything else.
It also closes a compliance gap most programs hit at audit time. SOC 2 Type II or HIPAA attestation on the underlying cloud doesn’t extend to the agent or tool plane unless the runtime layer is explicitly in scope. The agent plane is where the action actually happens: every tool call, every credential resolution, every policy decision. Compliance evidence has to follow the action, not stop at the infrastructure boundary. A governance runtime that ships SOC 2 Type II coverage at the agent and tool plane closes that gap directly.
10 AI agent governance anti-patterns that break runtime compliance
The right architecture matters, but knowing what breaks it matters as much. These ten traps are the patterns that render compliance efforts useless at audit time or during incident response.
1. AI governance by spreadsheet
Treating compliance as static documentation rather than a dynamic byproduct of runtime execution guarantees your security posture will drift from reality the moment code is deployed. Security controls must be expressed as code and enforced automatically, not verified manually through periodic spreadsheet updates.
2. Mutable application logs
Storing audit trails in standard, editable relational databases exposes you to massive compliance risks. Regulators and auditors demand immutable, replayable ledgers that prove an audit trail hasn’t been tampered with to hide a rogue agent’s actions or a developer’s mistake.
3. Identity collapse and shadow MCP servers
Using a single shared API key for all users interacting with an agent breaks attribution. When a breach occurs, you can’t tell which user triggered the action. Without centralized identity, shadow servers proliferate without oversight, creating invisible, ungoverned attack surfaces.
4. Credentials exposed to the agent
Storing API keys in the agent’s system prompt, passing OAuth tokens as parameters the LLM can see, or letting credentials touch the agent’s context window at any point creates a leak vector that no audit log can fix. A prompt injection that exfiltrates the credential is no different from one that exfiltrates user data. Credentials must be brokered by the runtime, scoped to the specific tool call, and never enter the agent’s context.
5. In-band chat approvals
Delivering human-in-the-loop approval prompts within the agent’s own chat interface creates a critical vulnerability. Adversarial prompt injections can forge these interfaces or trick the model into bypassing approval logic, authorizing destructive actions without genuine user consent.
6. Agent-side policy enforcement
Trusting the agent to enforce its own policy is like trusting a process to enforce its own permissions. LLMs can be prompt-injected to override their own guardrails, are non-deterministic about when they apply them, and produce no audit trail of what they decided or why. Policy enforcement must sit outside the agent, deterministic and auditable. The agent calls; the runtime decides.
7. Decentralized policy enforcement
When policy is enforced in multiple places (the agent’s system prompt, ad-hoc rules in tool wrappers, separate policy engines per team), there’s no single source of truth. Each enforcement point drifts. Each runs its own version. Auditors can’t replay decisions consistently, because no one can prove which policy authorized an action three months ago. Centralized, version-pinned policy enforcement at runtime is the only way to keep agent behavior consistent across teams and to make it replayable across audits.
8. No autonomy-tier classification
Treating every agent identically, regardless of risk, forces overinvestment in low-stakes workloads while underprotecting high-impact ones. Without a clear tier classification mapped to data sensitivity and action reversibility, governance strictness can’t scale with operational risk. Your security posture stays uniform when it should be proportional.
9. No revoke-and-rotate workflow
When an employee is offboarded or a credential is suspected to be compromised, you need to instantly rotate that user’s tokens and revoke their delegated agent access without disrupting the rest of the user base. Architectures built on shared service accounts can’t selectively revoke a single user’s access, forcing security teams to choose between all-or-nothing breakage.
10. Compliance attestation that covers the cloud but not the agent
A SOC 2 or HIPAA certificate on your cloud provider is not a certificate on your agent fleet. Many programs only discover this gap mid-audit, when the auditor asks for evidence of agent actions, policy decisions, and approvals, and the answer is “our cloud is certified,” which doesn’t address the question. The agent plane needs its own attestation scope, or it will remain inadmissible no matter how many infrastructure-layer reports you produce.
Implementation patterns for AI agent governance in regulated industries
Those are the failure modes. The flip side is what running the framework actually looks like in production, across highly regulated environments with distinct autonomy requirements.
Healthcare (HIPAA): Tier 1 approval and PHI logging
Consider a Tier 1 clinical note-summarization agent deployed under HIPAA. The contractual layer (Business Associate Agreements between covered entities and processors) sits outside the runtime, but the obligations it creates live within it: strict data boundaries, demonstrable PHI access controls, and an audit trail that proves who accessed what, when, and under whose authority.
Before any summarized note is committed back to an electronic health record system, the framework requires human-in-the-loop approval. The runtime logs the physician’s cryptographic signature alongside the exact prompt hash, the retrieved patient context, and the output hash. Every instance of access to Protected Health Information is immutably logged.
This pattern exercises three CISO concerns simultaneously: identity and attribution (the physician is the security principal), active prevention at the tool call (no PHI write without signed approval), and observability that the SIEM can use (every access is replayable). The contract still has to be signed, but the evidence to demonstrate it is generated automatically.
Financial services: Tier 2 bounded trade execution
Consider a Tier 2 bounded agent for compliant trade execution. The agent operates autonomously, but only within the pre-approved scope defined by policy-as-code.
A trader might ask the agent to rebalance a portfolio based on specific market signals. When the agent attempts the tool call to the trading API, the runtime intercepts the request and evaluates it against trading limits and risk parameters. The system records the exact policy version used to make the decision. If an auditor or regulator questions a trade later, you can replay the exact decision matrix, from the initial user prompt hash through the policy evaluation to the final output hash.
This pattern leans hardest on active prevention at the tool call (policy-as-code enforcement, version-pinned) and continuous audit-readiness (replayable decision matrices). Identity is the trader; attribution is the policy version. A regulator asking “why was this trade allowed?” has a deterministic answer.
Cross-industry: enterprise offboarding (Tier 1–2)
For large enterprises and public sector deployments running Tier 1 to Tier 2 agents, strict data residency and identity lifecycle management are most important.
Consider an employee undergoing an unexpected HR offboarding event. In a traditional setup with shared API keys, revoking access without breaking the agent for other users is nearly impossible. With an integrated runtime treating the agent as a distinct security principal tied to the user’s identity, the offboarding event automatically triggers token rotation. The system revokes that specific user’s delegated agent access instantly, ending in-flight operations and neutralizing the credential risk. No disruption to the rest of the organization.
This pattern is the clearest demonstration of identity and attribution doing their jobs. The service account problem is the failure mode that this prevents; per-agent identity tied to the requesting user is the resolution. If your runtime can’t pass an offboarding fire drill in under a minute, the rest of the rubric doesn’t matter.
Where each vendor category fits the agent governance rubric
The AI security market is highly fragmented. Enterprise architects end up stitching together disparate tools that were never designed for autonomous agents. The vendor landscape sorts into categories that Arcade integrates with, displaces at the agent action layer, or treats as out of scope. The difference matters.
Vendor categories and their relationship to Arcade
| Architectural layer | Example vendors | Relationship to Arcade | Why |
|---|---|---|---|
| SIEM and observability platforms | Datadog, Splunk, New Relic, Sumo Logic | Feed | Arcade exports OpenTelemetry GenAI events. Your security operations team queries them in the same SIEM they already use, with the same query syntax. The SIEM stays; the runtime sends it the agent-action layer it currently can’t see. |
| Policy engines and FGA platforms | Open Policy Agent, Cedar, OpenFGA, Oso (Polar DSL), WorkOS FGA | Complement | Define and evaluate fine-grained authorization rules. The runtime integrates with your policy engine and enforces those rules at the agent action layer, applying them in the per-user, per-tool, per-action context where agents actually act. |
| GRC platforms | Vanta, Drata, Secureframe | Complement | Map theoretical controls and automate attestation paperwork. Don’t govern the actual API tool calls an agent makes. Arcade integrates with your GRC platform and enforces those controls on every tool call. GRC declares; Arcade enforces. |
| Identity providers | Okta, Auth0, WorkOS, Clerk | Complement | Authenticate the human user. Stop at the human login boundary. Arcade brokers delegated agent tokens against the same IdP and extend identity into the agent action plane. |
| MCP gateways and integration wrappers | Composio | Displaces | Connect language models to tools for rapid prototyping. Lacks enterprise-grade identity isolation, just-in-time consent, out-of-band approval routing, and immutable audit at the agent plane. |
| Agent frameworks | LangChain, Mastra | Complement | Operate at the reasoning layer (deciding what the agent should do). Arcade governs the underlying action layer, decoupled from the framework. Pick a framework for reasoning and a runtime for action. They combine. |
| MCP runtimes | Arcade.dev | The unifying layer | Ships the complete 6-capability rubric natively. SOC 2 Type II coverage extends from the underlying cloud through to every tool call an agent makes. |
Relying on a patchwork of these vendor classes leaves significant security gaps and integration liabilities. A unified MCP runtime brings agent registration, per-user authorization, policy-as-code enforcement, immutable audit, and runtime attestation under a single, cohesive operating model. It extends the SIEM, IdP, and DLP investments your security team already runs.
Next steps to migrate to an MCP runtime for agent governance
Closing the gap between governance policy and runtime enforcement is a concrete engineering exercise. Four moves get you most of the way:
Audit your current agent and tool registry. Inventory every agent, every connected tool, every shadow MCP server, and every shared service account. If you can’t produce an authoritative list with owner, purpose, model version, autonomy tier, and approved users in under a day, your governance posture is already drifting.
Stop building bespoke audit infrastructure. Custom event-bus schemas, mutable application logs masquerading as audit trails, hand-rolled OpenTelemetry pipelines for agent traces. This is undifferentiated technical debt. Your engineers should ship governed agents, not maintain compliance plumbing.
Test revoke-and-rotate aggressively. Run an offboarding fire drill with a real test user. Verify that a single offboarding event rotates that user’s tokens, terminates in-flight agent operations on their behalf, and leaves every other user’s workflow undisturbed. If the workflow can’t do this in under a minute, your runtime can’t survive a real credential incident.
Evaluate an MCP runtime. Look for a runtime that ships the six governance capabilities natively, with SOC 2 Type II attestation that covers the agent and tool plane, not just the underlying cloud.
Stitching together passive observability tools and standalone policy engines can’t satisfy this requirement. Arcade.dev is the first MCP runtime to ship the complete agent governance rubric natively (runtime enforcement plus immutable, replayable audit), with SOC 2 Type II that extends from the underlying cloud to every tool call an agent makes.
Frequently asked questions (FAQ)
What is AI agent governance, and how is it different from LLM governance?
AI agent governance controls and proves what an agent can do, especially tool/API calls, using runtime policy enforcement, identity, and immutable audit trails. LLM governance often focuses on model behavior and outputs rather than execution-layer actions.
Why isn’t logging enough for AI agent compliance?
Logs are passive and occur after the fact. They can’t stop an undesired tool call or prompt-injection-driven action. Regulated environments require deterministic, pre-execution enforcement plus tamper-proof, replayable evidence.
Does an MCP runtime replace our SIEM?
No. It extends it. Every agent action emits an OpenTelemetry GenAI event into the same SIEM your security operations team already queries (Datadog, Splunk, New Relic, Sumo Logic). The runtime extends your SIEM into the agent action plane; it doesn’t displace it. The same model applies to your IdP (Okta, Entra, etc.) and DLP. The runtime extends those investments rather than running parallel to them.
Does this lock us into a specific agent framework?
No. A runtime governance layer is decoupled from the agent framework. LangChain, Mastra, your own in-house framework: whichever your AI/ML team picks for agent reasoning, the runtime governs the action layer underneath it the same way. Frameworks decide what the agent should do; the runtime governs whether and how it gets to do it.
What does “runtime enforcement at the tool-call boundary” mean?
Every tool/API request is intercepted, evaluated against policy-as-code, and either blocked, modified (e.g., redacted), or allowed before it reaches the resource server. Then it’s logged with the decision and policy version.
How do I choose the right autonomy tier for an agent?
Classify autonomy by data sensitivity, reversibility of actions, and potential legal/customer impact. Use Tier 1 (fully supervised, human approval per action) for high-stakes irreversible workloads. Tier 2 (constrained autonomy within pre-approved scope) is the default for the enterprise.
What are the minimum audit log fields required for agent governance?
See the canonical schema in Capability 5 above: Agent ID, User ID, Tool Call, System, and Timestamp at minimum. Stored immutably. Richer fields (prompt hash, retrieved-context references, policy version, output hash) enable full replay.
What is “policy version pinning” and why does it matter?
Policy version pinning records the exact policy version that authorized a specific action at that time. It prevents “silent compliance breaks” when policies change and enables auditors to accurately replay historical decisions.
Why are in-chat human approvals unsafe for agents?
In-band chat approvals can be spoofed or bypassed via prompt injection. Use out-of-band approvals (e.g., signed approvals bound to the tool-call hash) to cryptographically prove a human authorized the exact payload.
What does “agent-as-a-security-principal” mean?
Each agent gets its own identity and scoped credentials tied to the requesting user and tenant. This enables least privilege, clear attribution, and rapid revocation without relying on shared API keys.
Can we just use a service account per agent?
No. Shared or pooled service accounts break attribution (you can’t tell which user triggered an action), block selective revocation (you can’t rotate one user’s access without breaking everyone’s), and force all-or-nothing access decisions. The category requires per-agent identity tied to the requesting user, scoped to specific tools and actions, acquired just-in-time, and revocable in isolation.
How does this map to the EU AI Act, NIST AI RMF, and ISO 42001?
Those frameworks require traceability, monitoring, risk controls, and oversight. The runtime governance stack implements them operationally via identity, policy-as-code, immutable logs, HITL, and continuous assurance.
Our cloud provider is SOC 2 Type II certified. Isn’t that enough?
No. Cloud attestation doesn’t extend to the agent and tool plane unless the runtime layer is explicitly in scope. Auditors will ask for evidence of every agent action, every policy decision, and every approval. If your stack only attests at the infrastructure layer, the agent plane is unattested and inadmissible, regardless of your cloud provider’s certificate.
What are the most common anti-patterns in agent governance?
Ten patterns break runtime compliance: spreadsheet governance, mutable logs, identity collapse with shadow MCP servers, credentials exposed to the agent, in-band chat approvals, agent-side policy enforcement, decentralized policies, no autonomy-tier classification, no revoke-and-rotate workflow, and compliance attestation that covers the cloud but not the agent or tool plane. Each one breaks auditability or allows unauthorized actions to slip through.
