Architectural Patterns for Agent Runtime Governance: A Technical Companion to NIST's AI Agent Identity Project
The NIST National Cybersecurity Center of Excellence (NCCoE) recently published a concept paper titled Accelerating the Adoption of Software and AI Agent Identity and Authorization. The paper identifies six areas of interest where the industry needs to make progress: how AI agents should be identified, authorized, delegated, logged, governed for data flows, and defended against prompt injection.
NIST invited input from practitioners, vendors, and researchers. We submitted a technical companion: Architectural Patterns for Agent Runtime Governance, a 37-page document with 20 architectural sequence diagrams showing how existing standards like OAuth 2.0, OIDC, SPIFFE/SPIRE, SCIM, Cedar, AuthZEN, MCP, and A2A can compose into a governance architecture for AI agents.
Our core thesis is that a new architectural layer is emerging between traditional enterprise identity infrastructure and agent execution environments. We call this layer Agent Runtime Governance. IAM verifies who an agent is. Agent Runtime Governance verifies whether the agent should perform a specific action right now, given its declared purpose, its current authority grant, and the policies that govern its behavior.
The patterns we present are one perspective. We do not claim to have definitive answers. The challenges of agent identity and authorization are complex and will benefit from the diverse expertise of the NCCoE community. We offer these diagrams as concrete artifacts to ground discussion and invite collaboration on areas where our thinking may be incomplete or where alternative approaches may be stronger.
The Six Areas
How should AI agents be identified?
Agents require stable, cryptographically verifiable identity that is independent of the human who invoked them and the model that powers them. We illustrate how existing standards can compose to provide this: SPIFFE/SPIRE for workload identity, OIDC for authentication, SCIM for lifecycle provisioning. Together, these enable continuous discovery of agents across heterogeneous infrastructure, cryptographic attestation of their properties, and automated registration in a trusted registry.
How should AI agents be authorized?
Traditional authorization models (RBAC, PBAC, ABAC) were designed for humans and assume intent. We propose that agent authorization benefits from an additional layer: declared purpose, goals, and intent that are validated against the actual action on every request. A deterministic control plane that sits outside the agent evaluates every action against formal policy (Cedar, OPA, Rego). The control plane produces the same decision for the same inputs every time, in contrast to LLM-interpreted governance rules that may vary with context.
How should authority flow through delegation?
When an orchestrator agent delegates to sub-agents, authority should narrow at every hop. It should never widen. We demonstrate cryptographic delegation chains where each link is signed, scope-narrowed, and time-bound. We also identify the A2A (Agent-to-Agent) protocol as an area where governance extensions could be particularly valuable: delegation chain propagation, scope narrowing requirements, and cryptographic chain-of-custody verification.
How should agent actions be logged?
Agent audit records need richer context than traditional access logs. Not just "who accessed what" but under what authority, for what declared purpose, at what point in the agent's plan, and with what delegation chain. We demonstrate lifecycle-aware audit trails that capture the arc of planning, acting, and observing. We also introduce Execution Lineage: a tree-structured audit model where every agent action is a node connected by delegation, action, and resource-access edges, enabling complete reconstruction of multi-agent execution chains from any execution ID.
How should data flows be tracked?
Agents accumulate context (conversation history, tool results, user data) that is rarely treated as a governed data store. We demonstrate memory governance with classification, tenant isolation, retention policies, and deletion rights. For credential flows, we propose a capability token model where agents never hold raw secrets. Instead, they receive short-lived, purpose-bound tokens that are single-use, time-bounded, scope-locked, and audit-enriched.
How should architectures defend against prompt injection?
We believe the most durable defense against prompt injection is architectural rather than model-level: designing systems so that even a fully compromised model cannot take unauthorized action. We demonstrate two complementary layers. Content-level guardrails use policy-as-code (Rego) to detect and block injection patterns before content reaches the LLM. Action-level governance enforces six independent barriers (action whitelisting, intent-action validation, delegation chain scope, credential isolation, goal boundaries, behavioral detection) after the LLM responds. This containment approach bounds the blast radius of a successful injection to the agent's current, narrowly scoped authority grant.
The Missing Layer
Enterprise identity and access management is mature, well-standardized, and essential. Nothing in our submission proposes replacing it. What we propose is that AI agents introduce a category of runtime governance challenges that existing IAM infrastructure was not designed to address: dynamic planning and per-action authorization, delegated authority across agents, changing intent across lifecycle phases, memory and state governance, and containment of prompt injection consequences.
Agent Runtime Governance is a compositional layer. It consumes identity signals from existing IAM infrastructure and applies runtime-specific governance that IAM alone does not provide. The Enterprise Identity Plane provides foundational identity services. The ARG Layer adds runtime governance capabilities specific to autonomous agents. The Agent Execution Environment operates under the governance of both.
What Is New: Execution Lineage
Section 14 of the companion paper introduces Execution Lineage, a recent addition to our architectural patterns. Execution Lineage is a tree-structured audit model where every agent action is a node connected by delegation, action, and resource-access edges. Lineage context propagates across service boundaries via lightweight HTTP headers, and the persistent execution graph enables forensic reconstruction of any multi-agent chain from a single execution ID. The lineage graph also supports automatic anomaly detection: broken chains, denied-after-allowed-parent patterns, deep delegation warnings, and unusual fan-out.
We believe the community would benefit from discussing how execution lineage identifiers should be standardized and propagated across trust boundaries, particularly in multi-vendor agent environments.
Contributing to the Conversation
These patterns represent one perspective on how existing standards might compose into an agent governance architecture. The challenges are real, the standards landscape is evolving, and the right answers will emerge from the combined expertise of the community that NIST has convened.
We have published the full companion paper as a public resource: Architectural Patterns for Agent Runtime Governance (PDF). We welcome the community's input.
Read the full paper: Architectural Patterns for Agent Runtime Governance (PDF)
Learn more about Agent Runtime Governance or explore the Watchlight AI Beacon control plane.
Organizations interested in collaborating on these patterns can join the Founding Design Partner Program.
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)