DIRA: Dual-Intent Runtime Authorization

200-Level

Why Existing Authorization Fails for AI Agents

Role-based access control (RBAC) and attribute-based access control (ABAC) were designed for human principals making deliberate, bounded requests. A user authenticates, presents credentials, and requests a specific resource. The authorization system evaluates that request against a policy: does this principal, with these attributes, have permission for this action on this resource? The model assumes the principal is a human whose intent is implicit in the request. Requesting a file read means you want to read the file.

Autonomous agents break that assumption. An agent with read access to a document corpus can perform fundamentally different operations under the same permission grant: summarizing content for a user query, building an index for a legitimate pipeline, or systematically staging data for exfiltration. The permission is identical. The authorization check passes in all three cases. The difference between a compliant agent and a compromised one is not visible at the policy evaluation layer, because that layer was never designed to see it.

The audit trap: Audit logging records what happened after the fact. The value of a control is its ability to prevent unauthorized action, not to document it. A system that detects a data exfiltration event in the audit log has failed at the one thing authorization exists to do. The enforcement point has to be before the action executes, not after it completes.

The problem compounds in multi-agent systems. Modern agentic architectures involve orchestrators delegating tasks to subagents, tool-calling chains where a single user request fans out into dozens of downstream actions, and autonomous agents invoking other agents. At each delegation boundary, the original authorization context degrades. An orchestrator with user-delegated authority spawns a subagent that inherits that authority implicitly. That subagent invokes a tool that was never contemplated in the original delegation. The permission chain grows. The intent verification chain does not exist.

This is the principal confusion problem: the system cannot distinguish between an action the user authorized and an action that happened to fall within scope of what the user authorized, for reasons entirely unrelated to user intent. The behavioral controls that compensate for absent legal and social accountability in human systems simply do not exist for autonomous agents in any current framework.

300-Level

The DIRA Framework

DIRA defines three core principles. Together they address the control gap that static permission models leave open. Each principle maps to a specific failure mode in existing systems.

Principle 01

Intent Declaration

Every agent action must carry a declared intent payload at invocation time. Before an agent calls a tool, accesses a resource, or invokes an API, it must declare what it is trying to accomplish in a structured, machine-readable format. The declaration is not a comment or a log entry. It is a required input to the authorization decision.

The payload includes: action type (read, write, transform, transmit), target resource, declared purpose (summarize, index, forward, archive), originating task context, and the identity chain of any orchestrating agents above it in the call stack. This payload travels with the invocation, not separately.

Why it matters: Authorization systems that cannot observe intent cannot distinguish compliant from non-compliant behavior when the action type is identical. Requiring declaration creates an observable, machine-evaluable signal. It also creates a specific accountability surface: a declared purpose that does not match observed reach is an auditable anomaly, not an ambiguous behavioral pattern.

Principle 02

Dual Verification

Authorization checks declared intent against observed scope reach, in addition to checking role membership. The first check is traditional: does this principal have permission to perform this action type on this resource? The second check is new: does the observed resource access pattern match what the declared intent would predict?

An agent declaring "summarize document for user query" should access a bounded set of resources consistent with that task. If observed scope reach extends significantly beyond that set, the second check fails. The authorization engine does not need to classify the intent as malicious. It only needs to detect divergence between what was declared and what was observed.

Why it matters: Single-dimension authorization cannot detect behavioral deviation within a permitted scope. Dual verification creates a second enforcement axis. An agent can pass the role check and fail the behavioral check. Both must pass. Neither alone is sufficient.

Principle 03

Invocation-Time Enforcement

The enforcement point is at invocation, not in the audit log. When an agent calls a tool or API, the DIRA authorization engine evaluates the intent declaration and the predicted scope profile before the call executes. A deny decision blocks the action. An anomaly signal routes to a monitoring or escalation path. The action does not proceed while authorization is unresolved.

This requires the enforcement point to sit between the agent and the tool or API, not downstream of it. In practice this means the DIRA engine is a sidecar, a gateway, or an SDK-level intercept. The architectural requirement is that no tool call reaches its target without passing through the enforcement layer.

Why it matters: A system that detects unauthorized behavior in a post-hoc audit has failed the agent it was supposed to constrain. Invocation-time enforcement is the only model where authorization actually functions as a control rather than a record.

Framework	What It Addresses	Workload Identity	Runtime Intent Check	Behavioral Enforcement
SPIFFE / SPIRE	Cryptographic workload identity, SVID issuance, federation across trust domains	Yes	No	No
Singapore MAS MGF	Principal hierarchy, scoped permission delegation, governance model for AI systems	Partial	No	No
OWASP NHI Top 10	Non-human identity credential lifecycle, secret sprawl, privilege accumulation	Yes	No	No
OWASP Agentic AI Top 10	Privilege escalation risks, prompt injection, unsafe tool use patterns	Partial	No	No
NIST AI RMF	AI risk governance, measurement frameworks, organizational accountability	No	No	No
EU AI Act	Compliance classification, transparency obligations, conformity assessment	No	No	No
None	Defines a runtime intent verification protocol as an enforceable control category	No	No	No

300-Level

Reference Architecture

The diagram below shows the DIRA control flow from agent action to execution. Each component is a conceptual category, not a prescribed implementation. The architecture is designed to compose with existing infrastructure.

Component Descriptions

Intent Declaration Layer. Sits at the agent SDK or tool-call boundary. Accepts the agent's outbound action and requires attachment of the intent payload before forwarding. Stateless. Can be implemented as an SDK wrapper, a sidecar proxy, or an API gateway plugin. Blocks any invocation that does not carry a valid, signed intent declaration.

DIRA Authorization Engine. The core decision service. Receives the declared intent payload alongside the action request. Runs two checks in parallel: scope verification against the configured resource policy, and behavioral verification against the predicted scope profile for the declared purpose. Returns a grant, a deny, or an anomaly signal with context.

Scope Check. Evaluates the action request against standard access control policy: role membership, attribute predicates, resource permissions. This is the existing authorization check that most systems already perform. DIRA does not replace it.

Behavior Check. Evaluates the predicted resource reach for the declared intent against the observed or requested scope. A summarization task has a predictable reach profile. A data export task has a different one. Divergence between declared purpose and actual scope reach triggers the anomaly signal path. The check does not need to classify intent as malicious to be useful.

Anomaly Signal. Not a deny decision. Routes the invocation to a monitoring, escalation, or rate-limiting path while the scope check result is still evaluated. An anomaly on the behavior check does not automatically block the action, but it flags the session for elevated scrutiny and feeds session-level drift tracking. In high-trust environments, anomaly signals may trigger human-in-the-loop review.

Action Executes. The action reaches its target only when both checks pass. If the scope check denies, the action is blocked. If the behavior check signals an anomaly and policy dictates block-on-anomaly, the action is blocked. The target system sees no indication of a blocked request unless explicitly surfaced through an error response.

400-Level

Implementation Considerations

For practitioners building a DIRA-style system, the following sections address the key design decisions: what to put in the intent payload, where the enforcement point lives, what anomaly detection actually means in practice, and how to wire it into existing infrastructure.

The Intent Declaration Payload Schema

The payload must be machine-readable, signed by the agent identity, and immutable once declared. A minimal schema:

action_type:      "read" | "write" | "transform" | "transmit"
target:           "resource identifier or URI pattern"
declared_purpose: "summarize" | "index" | "forward" | "archive" | ...
task_id:          "originating task or session identifier"
principal_chain:  ["orchestrator-svid", "subagent-svid"]  # SPIFFE SVIDs
scope_assertion:  "predicted resource reach as set or pattern"
timestamp:        "ISO-8601 with millisecond precision"
signature:        "agent SVID signature over payload hash"

The principal_chain field carries the full delegation stack, not just the immediate caller. Each entry is a SPIFFE Verifiable Identity Document (SVID), making the chain cryptographically verifiable. The scope_assertion is the agent's self-declared prediction of what resources it expects to touch. This is what the behavior check evaluates against observed reach.

Enforcement Point Placement Architecture

The enforcement point must sit between the agent and the tool or API call. Three deployment patterns are viable:

SDK intercept. A wrapper around the agent's tool-calling library that attaches intent declarations and routes through the DIRA engine before dispatching. Works in environments where you control the agent code. Lowest latency, highest coverage.

Sidecar proxy. A lightweight sidecar container that intercepts all outbound calls from the agent process. Works for containerized agents without code modification. Requires network-level interception, similar to service mesh patterns. SPIFFE workload attestation integrates naturally here.

API gateway plugin. A plugin or policy layer at the API gateway that enforces intent declaration as a precondition for routing. Works well when agents access a bounded set of internal APIs. Less effective for arbitrary outbound HTTP.

Regardless of deployment model, the enforcement point must be the only path to the target. Bypass routes defeat the control. This is the same architectural requirement as Zero Trust microsegmentation: if there is an uncontrolled path, the control does not exist.

What "Anomaly Signal" Means in Practice Detection

The behavior check generates an anomaly signal when the observed or requested scope reach diverges from what the declared purpose predicts. This is not a classification problem and does not require a trained model to get started. A rule-based implementation is sufficient as a baseline:

A summarize action targeting three documents should not request read access to 300. A forward action with a declared target of an internal endpoint should not resolve an external domain. A transform action should not generate write traffic to a storage endpoint not listed in its scope assertion.

At higher maturity, the behavior check can incorporate statistical baselines: the typical scope profile for a given agent identity and declared purpose type, derived from historical sessions. Deviation from the statistical baseline gives more sensitivity in complex environments where permitted scope is inherently variable.

Session-Level Drift Tracking Detection

A single anomaly signal may be a false positive: an agent legitimately needing to access more resources than its initial scope assertion predicted. A pattern of anomalies across a session, or a progressive drift in declared purpose versus observed reach over time, is a stronger signal.

Session-level drift tracking maintains a per-session behavioral profile that accumulates the declared intent and observed scope for every action in the session. A session where declared purpose shifts from summarize to index to transmit in a short window, each check passing individually, may trigger a session-level alert even though no single check failed.

This is also the mechanism for detecting multi-step attacks: where a compromised agent proceeds through a sequence of legitimate-looking individual actions whose aggregate effect is unauthorized. No single invocation fails the DIRA check. The session drift check catches the pattern.

Integration with SPIFFE / SPIRE Identity Plane

SPIFFE/SPIRE is the identity foundation that DIRA builds on top of. SPIFFE provides the cryptographic workload identity (SVID) that makes the principal_chain field in the intent payload verifiable. Without reliable, attestation-backed identity for each agent in the delegation chain, the intent declaration cannot be trusted.

The integration pattern: SPIRE attests the workload and issues an SVID. The agent holds its SVID in-memory via the Workload API. When constructing an intent declaration, the agent signs the payload with its SVID private key. The DIRA engine verifies the signature against the SPIFFE trust bundle before processing the authorization check.

For multi-agent delegation chains, each agent in the chain signs and appends its SVID to the principal_chain array. The DIRA engine validates the entire chain. This is the mechanism that closes the principal confusion problem: every delegation hop is cryptographically accounted for.

Research Status and Open Questions

DIRA is not a ratified standard, a published specification, or a vendored product. It is a framework developed through analysis of existing authorization models and the failure modes they exhibit in agentic AI contexts. The following questions remain open and would benefit from empirical implementation work.

Open Research Questions

How should the scope assertion in the intent payload be structured for agents operating in open-ended task contexts where resource reach is genuinely unpredictable at declaration time?
What is the minimum viable behavioral baseline for a new agent identity with no historical session data? How should cold-start risk be managed?
How should the DIRA engine handle intent declaration for agent-to-agent calls where the downstream agent does not yet support the declaration protocol?
What is the appropriate escalation path when the behavior check signals an anomaly in a fully autonomous pipeline with no human in the loop?
Can session-level drift detection be implemented without creating new privacy risks through behavioral profiling of agent sessions that carry user data?
How does DIRA interact with prompt injection attacks, where an adversary attempts to override a legitimate agent's declared intent through injected instructions in retrieved content?
What implementation evidence would validate or falsify the core dual-verification claim: that checking declared intent against observed scope catches meaningfully different threats than scope checking alone?

Implementations that test these questions, whether confirming or challenging the framework, are the most valuable contributions. The framework is not an answer. It is a structured way of asking the right questions about a problem category that current tooling does not yet address.

Tool

DIRA Readiness Assessment

Five questions about your current agentic AI authorization posture. Each answer includes an explanation of the underlying control principle. The goal is to help you think through where your system stands relative to the DIRA model, regardless of your score.

Question 01 of 05

Do your AI agents declare intent before executing actions?

DIRA-aligned: Every agent action carries a signed intent payload specifying action type, declared purpose, and scope assertion before the call is dispatched. The declaration is a required input to the authorization decision, not optional metadata.

Question 02 of 05

Are authorization controls enforced at invocation time, or only at provisioning time?

DIRA-aligned: An enforcement point sits between the agent and every tool or API call. Authorization is evaluated per-invocation, not inherited from the provisioned role. A deny decision at invocation time blocks the action before it executes.

Question 03 of 05

Can your system distinguish between an agent reading data to summarize it versus exfiltrate it, given the same permissions?

DIRA-aligned: The behavior check evaluates declared purpose against observed scope reach. A summarization task has a predictable, bounded resource access profile. Deviation from that profile, such as sequential bulk reads or access to unrelated resources, triggers an anomaly signal regardless of whether the permission technically allows it.

Question 04 of 05

Do you have audit logs of agent actions? Do those logs inform real-time access decisions, or only post-hoc forensics?

DIRA-aligned: Session-level behavioral data informs the behavior check in real time. The enforcement point consumes the current session's action history to detect drift patterns before granting subsequent actions. Logs are also retained for forensics, but that is a secondary function.

Question 05 of 05

In a multi-agent chain, can you trace and verify authorization context at each hop?

DIRA-aligned: Every agent in a delegation chain signs the intent payload with its SPIFFE SVID and appends it to the principal_chain field. The DIRA engine validates the entire chain cryptographically before making an authorization decision. No hop is implicit or unaccountable.

Your DIRA Readiness Score

Dual-Intent Runtime Authorization