8. Verifiable Agentic Infrastructure

While OpenKedge determines whether an intent is admissible, Verifiable Agentic Infrastructure (VAI) governs the creation and scoping of authority once approved. In conventional environments, identity remains a static property of a user, service account, or workload. In agentic systems, this assumption fails. The primary security question shifts from who is calling to what validated intent justifies this specific authority at this exact moment.

Verifiable Agentic Infrastructure converts authorization from static privilege into proof-derived execution identity. In autonomous systems, privilege must result from verifiable proof rather than standing entitlement. VAI formalizes this proof-derived execution identity model in greater technical depth [1].

From Static Identity to Execution Identity

Traditional identity systems answer foundational questions: who is the caller, what role does the caller hold, what permissions are attached, and whether the principal is authenticated. These checks remain necessary; autonomous architectures still require authenticated actors, workloads, services, and execution environments.

However, they are no longer sufficient. Autonomous governance must also determine what intent was approved, which policy decision authorized the action, what context supported that decision, what contract bounds the execution, what authority is necessary, when that authority expires, and what evidence must be emitted.

Consequently, the unit of runtime trust shifts from principal identity to execution identity.

An execution identity is a task-scoped, time-bounded runtime authority derived from a validated intent, policy decision, context snapshot, and execution contract. It is not an ambient property of an agent; rather, it is a transient authority artifact created for a specific governed action under defined conditions.

This shift fundamentally alters the trust model. A conventional service account is trusted because it belongs to a pre-authorized service; an execution identity is trusted because the system can reconstruct the explicit reasoning that justified its issuance. The authority links directly to the approved task rather than inheriting ambient permissions from a broad role. The security question shifts from "Does this agent have access?" to "What proof justifies this authority now?"

This does not render principal identity irrelevant; the initiating actor still matters. A request from a human operator, an incident-response agent, a workflow system, or a deployment service carries distinct institutional weight. However, principal identity becomes merely one input to a richer authorization decision. The execution identity is the actual authority used for mutation, and it must remain narrower than the principal's general capability. In this model, a principal may be permitted to request a class of actions, while each execution receives only the task-specific authority that the validated contract justifies.

Why Standing Privilege Fails for Agents

Standing privilege grants a principal reusable, persistent authority that extends beyond a single task. While manageable in deterministic systems running stable software, standing privilege introduces severe vulnerabilities in autonomous agentic networks.

Static credentials define ambient capabilities in general; they cannot justify specific operations in real-time.

Standing privilege is persistent, reusable, detached from specific intent, difficult to bind to operational justification, vulnerable to tool-chain amplification, and highly dangerous when controlled by probabilistic agents. Even a least-privilege role remains too broad if it is not bound to intent, context, and time. A role that can restart services may be reasonable for a human operations team, but too broad for an agent responding to a single incident. A deployment credential may be reasonable for a CI/CD pipeline, but too broad for a code-generation agent. A workflow approval role may be valid for a human official, but unsafe for an autonomous process that interprets ambiguous instructions.

The problem is not that durable identities are inherently wrong; existing infrastructure depends on them. The problem is that autonomous execution must never inherit broad ambient authority simply because the agent is attached to a privileged principal. When a model can generate plans, chain tools, write code, and react to feedback, broad reusable credentials can amplify minor reasoning errors into catastrophic operational effects.

VAI does not eliminate identity management; it changes the derivation of runtime authority. The agent may have an identity sufficient to submit a request, but the authority to execute is minted only after the control plane validates the intent, policy decision, context, contract, and time bounds.

This distinction is vital for multi-step agent systems. A planning agent may ask for several operations in sequence. If it holds standing credentials, every step inherits the full permission set, even when later steps depend on assumptions from earlier ones. With proof-derived execution identity, each consequential step requires its own contract or a contract with explicit staged constraints. The system can stop, refresh context, request approval, or revoke authority between steps.

Standing privilege also weakens accountability. When a long-lived credential is used, an auditor may determine which principal acted, but not why that specific authority was justified at that moment. The result is a gap between access logs and institutional justification. VAI closes that gap by making the proof behind authority part of the identity lifecycle.

Proof-Derived Execution Identity

Proof-derived execution identity forms the core of VAI. Runtime authority derives from evidence that a specific intent was approved under specific conditions. The proof binds the intent, context, policy decision, execution contract, and time bounds into the identity issuance decision.

The relationship can be summarized as:

where I is the validated intent, C is the context snapshot, D is the governance decision, K is the execution contract, and T represents the relevant time bounds.

This formula does not prescribe one cryptographic construction; it expresses the architectural dependency: execution identity must not exist independently of governance evidence. An execution identity is valid only because the system can reconstruct the proof that justified its creation.

The resulting identity must be task-scoped, time-bounded, contract-bound, least-privilege, evidence-linked, revocable, non-transferable where possible, and auditable. It may be implemented as a short-lived credential, scoped token, capability token, workload identity, signed claim, session policy, or other runtime authority primitive. The implementation may vary; the invariant is that the authority is justified by proof and constrained by contract.

This distinction matters for audit and trust. A token by itself proves possession; a proof-derived execution identity proves that authority was minted because a governed decision authorized a bounded action. The difference is the connection to institutional evidence.

Proof-derived execution identity can be implemented with stronger or weaker technical guarantees depending on the environment. Some deployments may use signed tokens, cryptographic attestations, or hardware-backed workload identity. Others may begin with short-lived scoped credentials and strongly audited brokers. The architecture should not overclaim cryptographic properties that an implementation does not provide. What matters at the reference-architecture level is that authority issuance is linked to reconstructable proof and that enforcement points can verify the scope they are expected to enforce.

The proof must also be checked for consistency. The identity broker must reject a request if the actor does not match the approved contract, if the target resource differs, if the contract has expired, if the policy decision has been superseded, or if required evidence is missing. Proof validation is therefore an active control, not a database lookup.

The Execution Identity Lifecycle

Execution identity has a lifecycle. It begins after intent governance and ends when authority expires, is revoked, or is no longer needed. Treating this as a lifecycle prevents credentials from silently becoming durable privilege.

The lifecycle starts with intent approval. OpenKedge has evaluated the proposed action and produced a decision. If execution is allowed or constrained, the approved intent is bound into an execution contract. The identity broker then receives a request for runtime authority. That request must reference the approved evidence rather than merely asserting that a task is authorized.

Proof validation checks that the request matches the approved contract, that the contract has not expired, that the relevant policy decision is still valid, and that required context assumptions have not been invalidated. Only then is a credential or token issued. Runtime use then occurs through enforcement points that can verify the authority. Finally, the identity expires or is revoked, and the evidence chain preserves enough information for replay and audit.

This lifecycle must be visible to operators. A platform team must be able to see why a token was issued, what contract it was bound to, what it was allowed to do, whether it was used, when it expired, and whether any enforcement failures occurred.

Visibility is not only for auditors; it is also for operational safety. During an incident, responders need to know which autonomous actions are pending, which identities are live, which contracts are about to expire, and which actions were blocked. Without this view, proof-derived execution identity becomes another hidden control path. A mature VAI deployment must expose lifecycle state in a way that operators, security teams, and governance reviewers can understand.

The lifecycle must also support idempotency and uniqueness. If an agent retries an identity request, the system determines whether it is the same contract-bound execution or a new request requiring fresh validation. This prevents accidental duplicate authority and helps distinguish retries from replay attempts.

Binding Identity to Execution Contracts

The execution contract is the artifact that tells the runtime what is allowed. It defines the allowed action, target resources, permitted parameters, time window, maximum scope, context assumptions, evidence obligations, and revocation conditions. Execution identity must encode or enforce these constraints.

The execution contract describes what is allowed; execution identity makes only that authority usable.

Binding identity to the contract can happen in several ways. Short-lived credentials can be scoped to a narrow set of actions and resources. Scoped tokens can carry signed claims about target, operation, parameters, expiration, and contract id. Session policies can restrict a cloud credential to the approved operation. Capability tokens can encode a bounded right to perform one action. Workload identity federation can mint temporary workload authority after proof validation. Adapter-side enforcement can require a valid contract before calling downstream APIs. Policy decision points can verify contract claims at runtime.

In AWS-style environments, this may map to temporary STS credentials constrained by session policies and validated by an execution adapter. In Kubernetes-style environments, it may map to short-lived service account tokens, admission controls, and workload identity. In workflow systems, it may map to scoped workflow tokens and step-level authorization. These examples are implementation patterns, not requirements.

The architectural requirement is that the identity cannot be broader than the contract. If the contract authorizes a 10% traffic shift for a specific service in one region for ten minutes, the identity must not allow a 100% shift, another service, another region, or use after the window expires. If the contract authorizes a deployment to staging, the identity must not allow production changes.

Some environments cannot encode every contract constraint directly into the credential. In those cases, the contract must be enforced by another trusted component, such as an execution adapter, gateway, admission controller, workflow engine, or policy decision point. This is acceptable if the enforcement path is mandatory. It is not acceptable if the agent can bypass the adapter and use a broader credential directly. Contract binding is an end-to-end property, not merely a token format.

The contract must also bind evidence obligations. If post-execution verification is required, the runtime path must emit the corresponding evidence or mark the execution incomplete. If a rollback condition is triggered, the runtime must produce that event as evidence. This ensures that execution identity is connected not only to the permission to act, but to the responsibility to report what happened.

Runtime Enforcement

Execution identity matters only if runtime systems enforce it. Enforcement may occur at the identity broker, execution adapter, cloud API credential boundary, policy decision point, service mesh or proxy, workflow engine, deployment system, database gateway, code execution sandbox, or other control point close to the mutation.

Runtime enforcement must reject actions that do not match the approved contract, even if the agent attempts them.

The runtime enforces the contract, not the agent's memory of the contract.

An agent approved to shift 10% of traffic cannot shift 100%. An agent approved for one resource cannot mutate another. A contract that expired cannot be executed. A token issued for remediation cannot be reused for unrelated changes. A credential generated for one workflow step cannot be replayed into another step.

This independence from agent compliance is essential. The model may misremember the contract. The agent framework may attempt an extra tool call. A generated script may contain broader operations than intended. A human operator may accidentally pass the token to the wrong adapter. Runtime enforcement must not rely on good behavior from the reasoning layer; it must verify contract-bound authority at the point of use.

Enforcement must also emit evidence. Allowing an action, rejecting an out-of-contract attempt, detecting token reuse, or observing an expired contract are all evidence events. These events help distinguish agent failures from enforcement failures and governance failures.

The placement of enforcement points must match the consequence of the action. Low-risk internal operations may be adequately protected by an execution adapter and short-lived token. High-impact cloud, financial, public-sector, or safety-related operations may require multiple enforcement points: identity broker validation, adapter validation, target-system policy checks, and post-execution verification. The architecture allows layered enforcement without requiring every deployment to start at the highest assurance level.

Runtime enforcement also protects against drift between approval and action. A system may approve an action when capacity is healthy, but capacity may degrade before the token is used. A contract may be issued during an incident, but the incident state may change. Depending on risk class, the enforcement point may need to re-check selected context assumptions before execution.

Evidence and Justification

VAI produces evidence, not just credentials. Identity issuance, use, expiration, and revocation are part of the evidence chain.

A credential without evidence is a capability. A credential with reconstructable proof becomes accountable authority.

Evidence must include the identity request, referenced intent, referenced policy decision, referenced execution contract, proof validation result, issued authority scope, expiration time, runtime use, enforcement decisions, and revocation events. This evidence allows the institution to reconstruct not merely that a credential existed, but why it existed.

VAI contributes the identity and runtime segments of the IEEC. OpenKedge emits evidence that intent was evaluated and a contract was produced. VAI emits evidence that authority was requested, proof was validated, identity was issued, runtime use occurred, and authority ended. Together, those records connect proposed intent to actual execution.

This supports audit, replay, incident investigation, compliance review, non-repudiation where appropriate, and trust in autonomous execution. If an incident occurs, reviewers can determine whether the wrong authority was issued, the authority was misused, the enforcement point failed, the contract was too broad, or the original governance decision was flawed.

Evidence must be integrity-aware. The system must protect identity evidence from casual modification and preserve enough metadata to support replay. That does not require every deployment to use the same ledger, signature scheme, or evidence store. It requires that authority be reconstructable from durable records.

This evidence must include negative events. If an identity request is denied because the proof is stale, that denial is evidence. If an execution token is rejected because it is out of scope, that rejection is evidence. If a revocation request is issued, acknowledged, or fails, those events are evidence. Negative evidence shows that the system is enforcing governance, not merely recording successful actions.

Evidence also enables policy improvement. If many identity requests fail because contracts are underspecified, OpenKedge contract generation may need refinement. If many tokens expire before use, time windows may be too short or agents may be too slow. If runtime violations cluster around a certain adapter, the adapter may need stronger validation. VAI evidence is therefore both accountability material and operational feedback.

Revocation, Expiration, and Failure Handling

Expiration and revocation are first-class requirements for autonomous authority. Authority that cannot expire or be revoked is standing privilege by another name.

Autonomous authority must end when the time window expires, the intent is completed, context assumptions change, policy changes, risk signals change, execution fails, a human operator revokes it, evidence emission fails, or a contract violation is detected. The system should not assume that a credential remains valid just because it has not reached a long-lived IAM expiration date.

Failure handling must be conservative. If context becomes stale before execution, the runtime must pause, request refresh, or deny. If the evidence store is unavailable, high-risk actions must fail closed. If runtime use exceeds the contract, the system must reject the attempt and emit a violation event. If identity issuance fails, the system must not fall back to durable standing credentials. If revocation fails, the system must escalate and quarantine affected pathways where possible.

Revocation also needs to propagate to enforcement points. It is not enough for an identity broker to mark a token revoked if the execution adapter, gateway, or target system cannot observe that state. Practical designs may use short expiration windows to reduce reliance on active revocation, but high-risk actions still require explicit revocation behavior.

Failure handling must be visible in evidence. A failed issuance, expired token, denied runtime use, or failed revocation can be as important as a successful execution. These records show where the control plane protected the system and where operational gaps remain.

High-risk systems must prefer fail-closed behavior. If proof cannot be validated, identity must not be issued. If the evidence store cannot accept required events, execution must not proceed unless an explicit break-glass policy authorizes it. If an agent attempts to reuse authority outside its contract, the system must treat that as a governance event, not simply an application error. This posture may feel strict, but autonomous systems require clear failure boundaries because ambiguity can otherwise become unauthorized execution.

Break-glass behavior must itself be governed. Emergency access may be necessary in real operations, but it should not become a back door around VAI. Break-glass authority must be time-bounded, strongly evidenced, reviewed after use, and tied to institutional approval.

Implementation Patterns

VAI should integrate with existing identity systems rather than replace them wholesale.

The cloud adapter pattern is common for infrastructure operations. An OpenKedge contract enters an identity broker. The broker validates the proof. Short-lived cloud credentials are issued with narrow scope. An execution adapter performs the bounded operation. Evidence events are emitted before and after runtime use. This pattern can integrate with provider-native identity primitives while keeping the contract as the authority source.

The capability token pattern is useful where a runtime can verify signed claims directly. The contract produces a signed capability token that encodes allowed action, target, parameters, expiration, and contract id. The runtime verifies the token before execution. This can work for internal platforms, workflow engines, service meshes, and custom execution adapters.

The workflow identity pattern applies to business processes, public-sector systems, and regulated workflows. A workflow engine receives a scoped execution token. Approval and execution steps are bound to the contract. High-risk steps require escalation. Evidence records who or what approved the action, what authority was issued, and how the workflow used it.

The sandbox pattern applies when generated code or agent action must execute in a constrained environment. The sandbox permissions are derived from the contract. The generated code can access only the resources needed for the approved task. Outputs are verified before admission or deployment. If the generated code attempts out-of-contract actions, the sandbox rejects them and emits evidence.

Cedar, OPA/Rego, cloud-native policy systems, and institutional validators may participate in proof validation or runtime checks. VAI should not depend on a single policy engine. It should depend on a stable proof model: the identity broker must verify that the requested authority is justified by an approved contract and current evidence.

Implementation choices will vary across sovereign clouds, commercial clouds, private infrastructure, workflow systems, and regulated platforms. The invariant is that the runtime authority is task-scoped, time-bounded, contract-bound, and evidence-linked.

A practical rollout can begin by placing VAI around the highest-risk autonomous execution paths. For example, a platform team might first protect production infrastructure mutations, then extend the identity broker to deployment workflows, then add scoped tokens for data access and generated-code sandboxes. This incremental pattern is often more realistic than attempting to replace every credential at once. The reference architecture defines the direction: reduce standing privilege where autonomous systems can affect consequential state, and replace it with proof-derived execution identity.

Design Requirements

VAI implementations must satisfy several concrete requirements.

1. Task-scoped identity. The system must issue runtime authority for a specific governed task, not for open-ended agent activity.
2. Time-bounded authority. Credentials or tokens must expire quickly and align with the execution contract.
3. Contract-bound permissions. Authority must encode or enforce the approved action, target, parameters, and scope.
4. Proof validation before issuance. Identity brokers must validate intent, context, policy decision, contract, and time bounds before issuing authority.
5. Least privilege by construction. The system must derive only the minimum authority required by the contract.
6. Revocation and expiration. Authority must end when the contract expires, context changes, policy changes, execution completes, or risk conditions change.
7. Runtime enforcement independent of agent compliance. Enforcement points must reject out-of-contract actions even if an agent attempts them.
8. Evidence emission for every identity event. Requests, issuance, use, rejection, expiration, and revocation must all produce evidence.
9. Replayable justification. Auditors must be able to reconstruct why authority existed, what it allowed, how it was used, and when it ended.
10. Integration with existing IAM, workload identity, and policy systems. VAI must compose with existing infrastructure rather than force a replacement of identity investments.

VAI governs authority at runtime. The next chapter turns to the software construction boundary: how AI-generated code and system components are admitted before they are allowed to participate in governed execution.