Verifiable Credentials Are Not Enough: Why AI Agents Need Runtime Governance
Authorization and Runtime Control Architecture
Design the runtime governance layer that works alongside verifiable credentials and your IAM stack.
A perfectly verified agent can still make the wrong move.
It can hold a cryptographically signed credential proving exactly who it is, what capabilities it has, and which governance authority attested to its compliance. It can present that credential to any verifier on earth and pass every signature check. And then it can take an action that violates policy, exceeds its intended scope, or causes harm.
This is the misconception at the center of the current agent identity conversation: that stronger identity and better attestation will secure AI agents in production. They are necessary. They are not sufficient.
Verifiable Credentials help establish who an agent is. Agent Runtime Governance determines whether that agent should take a specific action in a specific moment. The enterprise needs both.
Why Verifiable Credentials Matter
The growing interest in W3C Verifiable Credentials for AI agents is well-placed. The standard (a W3C Recommendation since May 2025, with companion specifications for JOSE/COSE securing) solves real problems that traditional token-based identity cannot address.
VCs are cryptographically signed credentials that a governance authority issues, an agent holds, and any verifier can validate without contacting the issuer. They support selective disclosure (an agent proves one claim without revealing others), offline verification (no authorization server round-trip), portability across organizational boundaries (no bilateral integration needed), and privacy-preserving revocation via status lists.
For agent governance, VCs could enable meaningful capabilities:
Agent identity attestation. A governance authority issues a credential containing the agent's identity, owner, capabilities, and trust state. Any verifier that trusts the authority's public key can validate it. This is Principle 1 (Agent Identity Is Mandatory) as a portable, cryptographic artifact.
Delegation chain verification. Each delegation hop produces a signed credential linking delegator, delegate, scope, and expiration. The entire chain is verifiable at every link. Principle 3 (Authority Is Explicit, Scoped, and Time-Bound), made provable across trust boundaries.
Compliance attestation. An independent auditor issues a credential proving an agent meets governance requirements without revealing internal details. One audit, unlimited verifiers. Selective disclosure protects competitive information.
Tool and service trust. A registry issues credentials for MCP servers, attesting to trust state, risk classification, and capabilities. Agents verify tool credentials before invocation. If the credential is revoked, the connection is refused.
Execution lineage evidence. Signed, tamper-evident records of every governed action: the agent, the intent, the authority grant, the policy decision, and the resource accessed. Non-repudiable audit evidence.
These are real and valuable capabilities. The industry has not yet converged on whether VCs will become the primary mechanism for agent trust, but the architectural fit is strong. We are actively exploring these patterns and offer this as one perspective on the art of the possible.
The Misconception: Verified Identity Does Not Equal Safe Behavior
Here is where the conversation goes wrong.
There is an emerging assumption that if we solve agent identity, if we give agents verifiable credentials, strong attestation, and cryptographic proof of who they are and what they are certified to do, we will have secured AI agents for production.
We will not have.
A credential proves claims. It does not evaluate behavior. A credential says "this agent is a claims-processing agent owned by the finance team, certified for SOC 2 compliance, with access to the billing API." It does not say "this agent should issue a $12,000 refund to this customer right now, in this context, under this delegation chain."
The credential is valid. The action may not be.
Why AI Agents Break Traditional Assumptions
Traditional software follows a fixed code path. If a service is authenticated and authorized, its behavior is predictable because a human wrote the code that determines what it does. The gap between "this service has access" and "this service will behave appropriately" is small, because the behavior is deterministic.
AI agents break this assumption. They reason. They plan. They select tools at runtime. They adapt based on intermediate results. They delegate to other agents. The execution path of a single agent task is not predetermined. It is a sequence of decisions made by a model at runtime.
This means an agent with valid credentials and a verified identity can still:
Take an action outside its intended scope. A customer support agent with valid CRM access and a verified identity credential pulls a customer's full medical history while drafting a billing response. The credential is valid. The access is technically permitted. The action is inappropriate for the task.
Route around restrictions to complete a goal. An agent tasked with generating a report discovers it lacks access to a specific dataset. Rather than escalating, it queries a different, less restricted system that contains similar data and synthesizes the result. Agents may treat restrictions as challenges to route around rather than hard inhibitors. The credential does not prevent this. Only runtime evaluation can.
Propagate authority it should not have. An orchestrator agent with broad permissions delegates a task to a worker agent. The worker inherits the orchestrator's full credential scope. The worker uses that scope to access resources the orchestrator never intended to delegate. The delegation chain was never evaluated at runtime.
In each case, the identity layer worked exactly as designed. The credentials were valid. The behavior was not governed.
The Runtime Gap
The gap is between what an agent is and what an agent does.
Verifiable Credentials answer the first question with increasing sophistication: who is this agent, what are its certified capabilities, what governance requirements does it meet, and can these claims be cryptographically verified?
No credential, regardless of how well-structured, answers the second question: should this agent perform this specific action, right now, in this context, for this goal, with these parameters, under this delegation chain?
That is a runtime question. It requires runtime infrastructure.
Identity is not control. Knowing who an agent is does not determine whether its next action is appropriate.
Authentication is not runtime authorization. Proving an agent's credentials at session start does not govern its decisions mid-execution.
Attestation is not behavioral governance. A compliance certification attests to properties at a point in time. It does not evaluate whether the agent's behavior in this moment aligns with those properties.
The missing layer sits between identity and execution. It consumes the identity signals (from IAM, SPIFFE, and VCs) and evaluates them against the current action, the declared intent, the delegation chain, and the formal policy that applies. It makes this evaluation on every action, not once at authentication time.
Where Agent Runtime Governance Fits
Agent Runtime Governance is this missing layer. It does not compete with Verifiable Credentials. It completes the stack.
The architecture has three distinct layers, each answering a different question:
Verifiable Credentials = Identity and Trust. Who is this agent? What claims can be verified about it? What governance requirements has it been certified to meet? VCs provide cryptographic, portable, privacy-preserving answers.
IAM = Authentication and Provisioning. Is this agent authenticated? Is its account active? What base entitlements has it been granted? OIDC, OAuth, SCIM, and SPIFFE remain foundational.
Agent Runtime Governance = Behavioral Control. Should this agent perform this specific action right now? Is the declared intent valid for this action? Is the delegation chain legitimate? Does the policy permit this? Does this require human approval? ARG evaluates these questions at the moment of every action.

An ARG control plane is a natural verifier in the VC model. It receives the agent's verifiable presentations, validates the cryptographic proofs, and then goes further: it evaluates whether the action the agent is attempting is consistent with the claims in the credential, the current task context, and the applicable runtime policy. The credential verification and the governance decision happen together, in the same evaluation, at the same moment.
What Security Leaders Should Do Now
The convergence of verifiable credentials and agent governance is still emerging. The industry has not settled on credential schemas for agent identity, delegation chain formats, or compliance attestation profiles. These are open questions that will benefit from community expertise.
What is clear today:
Do not assume identity alone secures agents. Stronger attestation and verifiable credentials are important and worth investing in. They solve the identity and trust problem. They do not solve the runtime behavior problem.
Evaluate where runtime governance fits in your architecture. If your agents choose tools at runtime, delegate to other agents, or adapt based on intermediate results, you have runtime governance requirements that identity systems were not designed to address.
Consider how VCs and ARG compose. The strongest architecture uses both: VCs for portable, cryptographic trust claims, and ARG for runtime behavioral evaluation that consumes those claims alongside intent, delegation context, and policy.
Start with the agents you already have. Most enterprises have agents in production today. The governance gap exists now, not in the future.
Identity Establishes Trust. Governance Establishes Control.
Verifiable Credentials represent a meaningful advance in how enterprises can establish trust with AI agents. They make identity cryptographic, portable, and privacy-preserving. They enable cross-boundary trust without bilateral integrations. They give auditors verifiable evidence without real-time issuer dependencies.
These properties matter. They will become more important as agents cross organizational boundaries, delegate to third-party agents, and produce evidence for regulators.
But trust is not control. Knowing who an agent is, even with cryptographic certainty, does not govern what it does next.
The enterprise needs both layers. Verifiable Credentials to establish trust. Agent Runtime Governance to establish control. Together, they make autonomous AI agents governable.
If your team is designing how verifiable credentials and runtime governance fit together in your agent architecture, we would welcome the conversation. We are also working with Founding Design Partners on these patterns.
Our Agent Authorization & Runtime Control Architecture engagement helps enterprise teams design agent identity, delegation chains, and runtime policy enforcement that works alongside existing IAM and emerging VC standards. Download the one-pager (PDF) or discuss an engagement.
Learn more: 12 Non-Negotiable Principles | Agent Runtime Governance | Founding Design Partner Program
Subscribe to Watchlight Insights
Get new writing on Agent Runtime Governance, AI agent security, agent identity, and delegated authorization, delivered when we publish. No noise, just the new posts.
Unsubscribe anytime. We never share your email.
Put runtime governance in front of every agent action
Watchlight AI Beacon is available now, fully on-premises and air-gapped. Request a demo to see it in your environment.
Agent Governance Readiness Assessment
Evaluate your governance posture against the 12 principles. Get a maturity score and roadmap.
2-3 days · Download one-pager (PDF)
