DEV Community: Bhanuj Kashyap

Identity Is Only the Beginning: Exploring Runtime Governance for AI Agents

Bhanuj Kashyap — Wed, 28 Oct 2026 12:27:29 +0000

An architectural perspective on agent identity, delegated authority, runtime authorization, and execution evidence, informed by Auth0's Agent as Principal and Agent Gateway.

Introduction

As AI agents evolve from conversational assistants into systems capable of executing real-world actions, their security boundaries become considerably more complicated. An agent that retrieves information presents one class of risk. An agent that can modify customer records, invoke financial transactions, provision infrastructure, or delegate work to another agent introduces an entirely different set of architectural concerns.

Traditional identity and access management systems have spent decades refining how humans and applications authenticate and access protected resources. However, autonomous agents challenge several assumptions embedded in those systems. They can operate with or without an active user session, maintain execution context across multiple tools, and make decisions that were not explicitly enumerated when their credentials were issued.

I recently came across two articles from Auth0 that explain these challenges particularly well: Agent as Principal: A Purpose-Built Identity for Agents and Auth0 Agent Gateway: The Identity Control Plane for Customer-Facing AI. Together, they describe an approach in which agents have distinct identities, delegated authority is preserved, and tool invocations are evaluated within the appropriate security context.

What interested me was the architectural convergence with some of the problems we have been addressing while developing BHANUJ, an open-source agent governance platform.

Our scope is different. We are not building an identity provider, replacing OAuth infrastructure, or attempting to reproduce Auth0's enterprise identity capabilities. Our work focuses on runtime governance, trusted delegation, authorization decisions, and execution evidence.

Nevertheless, both approaches expose a fundamental architectural question: How do we preserve accountability and enforce security boundaries when software is no longer simply executing predefined instructions, but making decisions about which actions to perform?

1. Traditional Application Identity

Consider a conventional application that connects to an external API. The application authenticates using a service account or OAuth client, receives an access token, and makes requests within its assigned permissions. Although these permissions may be broad, the application generally follows execution paths designed and reviewed by engineers.

Now introduce an AI agent.

The same application might allow an agent to select tools dynamically, formulate requests, and determine which operations are necessary to fulfil a user's objective. The agent could execute dozens of actions using the same underlying credentials, even though each action carries a different business risk.

For example, consider an enterprise banking assistant authorized to help a customer manage their accounts. The assistant may retrieve transactions, categorize expenses, and prepare a payment. These operations share the same user context, but they should not automatically inherit identical execution privileges.

Reading transaction history is not equivalent to initiating a payment. Preparing a payment is not equivalent to submitting it. Similarly, a user granting an agent access to their account does not necessarily authorize every operation that the connected API supports.

This creates a distinction between authentication, delegated authority, and authorization at the point of execution.

Security concern	Traditional application model	Agentic execution model
Identity	Typically identifies a user, application, or service account	Must distinguish the agent, application, user, and potentially other delegated actors
Authorization	Often based on predefined roles, scopes, and application permissions	May require decisions specific to the proposed action, execution context, and delegated authority
Execution behaviour	Primarily follows application-controlled workflows	May select actions dynamically based on goals and runtime observations
Delegation	Often limited to known service-to-service relationships	May involve multiple agents acting across several delegation boundaries
Accountability	Logs commonly identify users, services, and API calls	Requires correlation between agent identity, delegated authority, policy decisions, and observed actions
Revocation	Disables credentials, sessions, or application access	May also need to terminate outstanding authority and prevent additional agent actions

The challenge is not that established identity standards have become obsolete. OAuth, OpenID Connect, and conventional access controls remain fundamental.

The problem is that authenticating an agent does not establish that every action the agent subsequently chooses is appropriate.

2. Auth0's Approach: Treating Agents as First-Class Principals

Auth0's Agent as Principal introduces an important distinction between an agent and the underlying application credentials used to authenticate it.

Rather than treating an agent merely as another machine-to-machine client, the approach gives the agent a persistent identity that can be associated with different execution modes. An agent might operate on behalf of an authenticated user in one workflow and execute autonomously in another. Its identity remains consistent even when the credentials or application context change.

One particularly relevant detail is the use of OAuth token exchange and actor claims to preserve delegation relationships. When an agent performs an operation on behalf of a user, downstream systems need sufficient information to distinguish the original authority from the actor exercising it.

This addresses a subtle but consequential security problem.

Without an explicit delegation model, an agent may authenticate successfully to a downstream service while losing the context explaining why it was authorized to act in the first place. Each system can appear individually secure, yet the complete execution chain becomes difficult to reconstruct.

Auth0's Agent Gateway extends this identity model into the tool invocation path. It introduces runtime authorization, contextual policy evaluation, credential brokering, and administrative controls designed for customer-facing agents operating across multiple tenants.

The gateway can evaluate requests against agent, user, and organization context while keeping downstream credentials outside the agent's direct control. This matters because giving an agent access to a credential effectively gives the execution environment an additional capability that may be difficult to constrain after the credential is exposed.

Together, the two capabilities illustrate how identity infrastructure can evolve to accommodate autonomous execution without abandoning established security protocols.

3. BHANUJ AIGP's Runtime Governance

While exploring similar security boundaries in BHANUJ OSS, we approached the problem from the execution side rather than from identity issuance.

Our starting point was a practical architectural concern: an agent framework already knows how to orchestrate agents, invoke tools, and manage workflow state. Should a governance platform duplicate those responsibilities simply to enforce policies and capture evidence?

We concluded that governance should remain a separate concern.

The agent framework should retain ownership of execution. Identity providers should remain authoritative for authentication and credential lifecycle management. The governance layer should evaluate explicitly submitted actions against applicable policies and preserve bounded evidence of those decisions.

This separation has influenced the design of our open-source capabilities, particularly trusted delegation, runtime action authorization, and framework-integrated execution evidence.

The relationship between these components becomes clearer when we compare their responsibilities.

Architectural dimension	Auth0 approach	BHANUJ OSS approach
Agent identity	First-class agent principals with lifecycle management	Governance identifies participating actors and execution context; it does not replace an identity provider
Delegated authority	OAuth token exchange and actor-aware identity context	Trusted delegation relationships and bounded execution authority
Runtime authorization	Gateway evaluates tool requests using identity and policy context	Runtime Action Authorization evaluates proposed operations against governance policies
Credential management	Token Vault, short-lived gateway credentials, and token brokering	Credential lifecycle remains an external infrastructure responsibility
Execution ownership	Gateway mediates supported downstream tool access	Agent framework retains orchestration and execution ownership
Evidence	Identity-linked action logging and tenant audit integration	Bounded execution evidence, policy decisions, and integrity-oriented references
Enforcement	Gateway can mediate and enforce tool access	Integration must honor the governance decision at the actual execution boundary
Advanced assurance	Identity, policy, credential, and access controls	Causal replay and formal bundle attestation are longer-term capabilities, not current OSS claims

These are not statements of feature equivalence. The systems operate at different architectural boundaries, and their enforcement guarantees depend on their respective integrations.

The important convergence is conceptual: authorization cannot simply be inferred from the existence of a valid identity, and accountability requires more than collecting application logs after execution.

4. Example: An Agent Initiating a Payment

Consider a customer asking an AI banking assistant to transfer $5,000 from a savings account to another account.

Assume the customer is authenticated and the agent has legitimate access to the bank's payment APIs. The agent retrieves the relevant account information and prepares a transfer instruction.

At this point, authentication has established who the user is and which application or agent is operating. However, the presence of a valid token does not necessarily establish that this particular payment should proceed.

The system may need to determine whether the destination is permitted, whether the transfer exceeds the customer's configured limits, whether additional approval is required, and whether the agent's delegated authority includes payment execution rather than merely payment preparation.

A robust architecture separates these responsibilities.

Execution stage	Question being answered	Responsible architectural layer
Authentication	Who is the user and which agent is acting?	Identity provider
Delegation	What authority has the user or calling system granted?	Identity and delegation infrastructure
Action proposal	What payment does the agent intend to initiate?	Agent runtime
Policy evaluation	Does this action satisfy the applicable execution constraints?	Runtime governance
Enforcement	Has the authorization decision been enforced before the payment API executes?	Tool gateway, application, or API enforcement point
Execution	Was the payment accepted, rejected, or left in an indeterminate state?	Banking service
Evidence	What was requested, decided, and observed?	Governance evidence and operational audit systems

Suppose the policy requires explicit customer confirmation for payments above $2,000. The governance layer can return a decision indicating that the proposed $5,000 payment must not proceed without the required approval.

However, there is an important architectural subtlety. Returning a DENY decision is not the same as preventing execution.

If the agent runtime ignores the decision and calls the payment API directly, the policy engine has not provided an effective security boundary. Enforcement must occur at a point the agent cannot bypass, or the protected service must independently validate the required authorization.

Similarly, the system must account for what happens if a policy service becomes unavailable, a request is retried, or the delegated authority changes between evaluation and execution.

These are not theoretical edge cases. They determine whether runtime governance is genuinely enforceable or merely advisory.

For financial operations, the underlying transaction system must also continue to enforce its own business rules, approval requirements, and idempotency guarantees. An agent governance decision does not replace the bank's transaction authorization controls.

5. Authorization Decisions & Execution Evidence

This distinction became particularly important during our work on execution evidence.

A governance system may accurately record that a proposed action was allowed, but this does not establish that the action completed successfully. Conversely, an application may report that an operation succeeded without preserving sufficient information to explain which authority permitted it.

These represent different facts.

The authorization decision records what the governance system permitted at a particular boundary. Execution evidence records what the integration observed during the subsequent operation. The downstream system remains authoritative for the actual business outcome.

For example, an agent might receive authorization to initiate a payment, invoke the API, and then encounter a network timeout. The governance record may show ALLOW, while the client-side execution status remains uncertain. Only reconciliation with the payment system can establish whether the transaction was committed.

Treating these observations as interchangeable creates misleading audit trails.

Our open-source work therefore emphasizes bounded evidence, explicit identities for tool invocations, policy decisions, and integrity-oriented references. The objective is to preserve useful execution facts without indiscriminately collecting prompts, credentials, sensitive business data, or internal model reasoning.

This is also where our longer-term exploration of causal replay and evidence attestation becomes relevant. Reconstructing why a particular outcome occurred is a different problem from proving that an agent was authenticated or authorized.

Those advanced capabilities remain areas of development. Nevertheless, separating identity, authorization, observed execution, and causal explanation from the outset provides a more coherent foundation for evolving the architecture.

6. Architectural Boundaries

There is an understandable temptation to centralize identity, authorization, policy management, credential handling, execution, and auditing into a single agent security platform.

Such consolidation may simplify early demonstrations, but it can also introduce operational coupling. A governance component can inadvertently become responsible for credential availability, tool orchestration, transaction handling, and execution recovery, even when those responsibilities belong elsewhere.

We have deliberately tried to avoid that direction.

A composable architecture should establish clear ownership between its control plane and enforcement points. It should make data contracts explicit, preserve failure isolation where feasible, and avoid hidden dependencies between security decisions and downstream execution.

Several engineering considerations follow from this approach.

Authorization context must be explicit. A policy engine should not be required to infer a user's identity, tenant, or delegated authority from unrelated application state. The request contract should identify the relevant actors, operation, resource, and supporting authorization context.

Enforcement must be independently verifiable. Integrating an authorization API into a framework does not automatically guarantee that every sensitive operation is mediated. Unprotected execution paths and direct API access remain architectural risks.

Governance failures need defined behaviour. A timeout or unavailable policy engine must not silently become permission to execute a sensitive action. Failure handling should be explicit and proportionate to the risk of the operation.

Evidence should be useful without becoming a liability. Capturing every prompt, response, credential, and payload may appear attractive for auditability, but it creates substantial privacy, retention, and security concerns. Bounded metadata and protected references often provide a more sustainable approach.

Component boundaries should support independent evolution. Identity infrastructure, governance policy, agent runtimes, and downstream services have different owners and release cycles. Their integration should rely on versioned, explicit contracts rather than implicit assumptions about one another's implementation.

None of these principles is unique to agentic AI. They are established distributed-systems and security engineering practices. Autonomous execution simply makes the consequences of violating them more visible.

7. What We Have Built, and What Remains

BHANUJ.AI is still evolving, and it would be misleading to describe it as a complete enterprise agent security platform.

Our current implementation work has established foundational governance components, including trusted delegation, runtime action authorization, policy decisions, bounded execution evidence, and framework integration. These provide a practical starting point for experimenting with agent security boundaries and examining how decisions are represented during execution.

At the same time, significant enterprise concerns require further validation and development. These include comprehensive enforcement coverage, large-scale policy administration, distributed revocation behaviour, operational resilience, integration with external identity systems, and advanced evidence assurance.

We have also intentionally avoided owning responsibilities better served by established infrastructure. Credential issuance, enterprise authentication, and general-purpose identity lifecycle management should not need to be recreated inside an execution governance platform.

That boundary is not an indication that those capabilities are unimportant. It reflects an architectural decision about where they belong.

In that sense, the relevance of Auth0's work is particularly encouraging. It demonstrates how sophisticated identity and delegation infrastructure can address one part of the agent security problem, while independently developed governance components can explore complementary concerns at the execution boundary.

Conclusion: From Identity to Accountable Execution

The transition from traditional applications to autonomous agents does not invalidate existing security architecture. It requires us to apply those principles across a more dynamic execution model.

Identity establishes who is acting. Delegation establishes the authority under which they operate. Runtime authorization evaluates whether a particular action is permissible. Enforcement ensures that the decision is respected. Execution evidence helps explain what was subsequently observed.

Each responsibility is valuable independently, but the relationships between them determine the trustworthiness of the complete system.

Reading Auth0's Agent as Principal and Agent Gateway articles reinforced the importance of these boundaries. Our work on BHANUJ OSS has approached the problem from a different direction, but many of the underlying architectural considerations are remarkably consistent.

For me, the most interesting engineering challenge is no longer just how to give agents identities or permissions. It is how to construct an execution environment in which authority remains explicit, decisions remain enforceable, and consequential actions remain accountable.

That is the problem we are continuing to explore through open-source implementation.

References

Auth0 — Agent as Principal: A Purpose-Built Identity for Agents

https://auth0.com/blog/agent-as-principal-purpose-built-identity-for-agents/

Auth0 — Agent Gateway: The Identity Control Plane for Customer-Facing AI

https://auth0.com/blog/auth0-agent-gateway-beta/

BHANUJ — Agent Governance Documentation

https://governance.bhanuj.ai/docs/runtime-action-authorization
https://governance.bhanuj.ai/docs/policy-engine

Your AI Agent Has Permission to Run. But Who Authorized That Database Change?

Bhanuj Kashyap — Mon, 19 Oct 2026 08:08:11 +0000

AI agents are becoming increasingly capable of interacting with operational systems. They can query databases, update records, invoke APIs, and coordinate workflows across applications.

Scenario: An operations assistant receives the following request:

Put operational record OPS-001 into maintenance mode.

The assistant understands the request. It identifies the appropriate tool and prepares to execute it.

Should understanding the request be sufficient authorization to modify the database?

Of course not.

Yet this is precisely the security boundary that becomes difficult to reason about as AI agents gain access to more tools and enterprise systems.

I wanted to explore how we could enforce authorization independently of an agent's reasoning, without replacing the agent framework or introducing another orchestration engine. So I built a practical experiment using LangGraph, SQLite, and BHANUJ-AIGP, an open-source AI governance platform.

1. Problem: Tool access is not task authorization

Imagine an operations assistant with two capabilities:

operations.read_status — inspect an operational record.
operations.update_status — modify that record.

The assistant receives a request to update record OPS-001 from PENDING to MAINTENANCE.

Technically, it knows how to perform the operation.

But several questions remain unanswered:

Who authorized this particular operation?
Does that authorization apply to this specific record?
Is the permission still valid?
Could the agent reuse the permission for another operation?
What happens if the authorization service becomes unavailable?
Can we later establish which decision permitted the database modification?

These questions are distinct from whether the model selected the correct tool.

Tool selection determines what an agent intends to do. Authorization determines what it is permitted to do.

2. Architecture: Separate execution from authorization

The experiment deliberately retains LangGraph as the workflow engine. LangGraph owns the execution. It reads the record, prepares the proposed change, and invokes the tool when permitted. BHANUJ-AIGP owns the independent authorization decision and receives execution evidence.

The architecture follows this sequence:

User requests an operation
           |
           v
      LangGraph Agent
           |
           v
   Read current record
           |
           v
   Propose database update
           |
           v
    Authorization Check
           |
           v
        AIGP OSS
     Policy Decision
        /      \
      ALLOW    DENY
        |        |
        v        v
     SQLite     Stop
      Update   No Change
        |
        v
    Record Tool
     Execution

There is one important architectural distinction here.

AIGP does not execute the database operation.

The LangGraph integration enforces the returned authorization decision immediately before invoking SQLite. This preserves a clear separation of responsibilities:

LangGraph: Workflow execution and tool invocation.
AIGP: Policy evaluation, authorization decisions, and evidence management.
SQLite: Application data and state.

The goal is not to make the agent framework responsible for an entirely new governance system. It is to introduce an explicit security boundary at the point where an AI decision becomes a real-world action.

3. Authentication vs Delegated Authority

This was one of the most interesting parts of the experiment. A runtime can have a valid identity without being authorized to perform every operation. In the lab, Keycloak authenticates two separate service identities.

The delegation issuer

A trusted application identity that has permission to issue narrowly scoped delegation.

The agent runtime

A separate identity that executes the LangGraph workflow and requests authorization before performing a protected operation.

The runtime cannot simply declare its own authority. Before execution, the integrating application establishes a delegation bound to a particular execution, runtime identity, action, resource, and expiry. The authorization service validates and persists that delegation. When the runtime later proposes a protected tool call, the authorization service independently verifies the delegation and applicable policies.

This introduces two distinct controls:

Is the issuer authorized to delegate this action?
Is the runtime's proposed operation permitted by the applicable policy and delegation?

The agent cannot select a convenient policy or expand the delegation by changing its prompt.

This matters because an authenticated agent is not necessarily an authorized agent.

4. The Experiment: An authorized database update

Let's consider the permitted scenario. Our local SQLite database initially contains:

Record: OPS-001
Status: PENDING

The LangGraph assistant proposes:

Action: operations.update_status
Resource: operational-record:OPS-001
New status: MAINTENANCE

Before SQLite executes the update, the runtime requests authorization from AIGP. AIGP evaluates the stored execution-scoped delegation and the active applicable policies. For this scenario, authorization is granted.

The resulting lab output includes:

Outcome: WRITE_COMPLETED
Reason: ALLOW_POLICY_MATCHED
SQLite record status: MAINTENANCE
AIGP evidence status: COMPLETED

The operation succeeds because the specific action satisfies the authorization requirements.

Not merely because the agent has access to the tool.

5. Remove Authority

Here's where the experiment becomes more interesting. Suppose the runtime receives a delegation that permits only:

operations.read_status

But it attempts:

operations.update_status

The proposed operation exceeds the delegated authority. The policy decision is:

DENY — DELEGATION_SCOPE_DENIED

Result:

Database status: PENDING
Successful TOOL_CALL events: 0

The protected mutation never executes. This denial was validated against the running AIGP OSS API, rather than merely simulated by a local mock. An interesting detail - the overall agent execution can still finish successfully because it handled the denial safely.

That exposes another important distinction:

Successful workflow completion does not imply successful or authorized tool execution.

A well-behaved assistant may complete its task by reporting that the requested action was not permitted. The workflow outcome and the authorization outcome need to remain separate.

6. What happens if the authorization service goes down?

A security boundary is useful only if its failure behavior is predictable. Suppose the agent attempts a protected database operation, but the authorization service times out. Should the assistant proceed because the request appears legitimate?

No.

For protected operations, the integration follows a fail-closed design. A denied decision, expired authorization, invalid response, mismatched operation, or unavailable authorization service prevents the database write.

The lab also includes deterministic offline failure exercises for these behaviors. Importantly, those offline fixtures are not presented as genuine AIGP authorization decisions. The aigp scenario uses the authoritative API; allowed, denied, and outage are local teaching and testing scenarios.

This distinction matters when evaluating whether a security architecture actually works outside a demonstration.

7. Authorization Without Evidence

Preventing an unauthorized operation is essential. But operational teams also need to understand what happened afterward. Consider an investigation:

An agent changed an operational record. Was the change permitted? Which execution performed it? Which authorization decision preceded the tool call?

In this experiment, the AIGP integration records a bounded execution history. A typical sequence includes:

EXECUTION_STARTED
        |
        v
WORKFLOW_STEP
        |
        v
RUNTIME_ACTION_AUTHORIZATION
        |
        v
TOOL_CALL
        |
        v
EXECUTION_COMPLETED

A successful tool-call record references the authorization decision through a causation_id. That allows a reviewer to connect the runtime-reported action to the decision that authorized it. The evidence is deliberately privacy-bounded. It includes identifiers, decision metadata, outcomes, and references rather than storing raw prompts, complete tool payloads, credentials, or model reasoning. There is also an important limitation: AIGP receives the runtime-reported tool outcome. It does not independently witness the SQLite transaction.

This is useful authorization provenance and execution evidence, not an immutable proof of every underlying database effect.

8. Why not implement authorization entirely inside LangGraph?

You absolutely can implement conditional checks inside a LangGraph workflow. The question is whether those checks should constitute the authoritative security boundary. For a small, isolated experiment, local checks may be sufficient.

However, enterprise systems introduce additional requirements:

Multiple agents built using different frameworks.
Shared enterprise policies.
Independent policy administration.
Explicit delegation and revocation.
Consistent denial behavior.
Centralized authorization evidence.
Operational visibility across executions.

Embedding authoritative policies independently inside every agent implementation risks creating inconsistent enforcement.

One framework may enforce a rule differently from another. A future tool integration might bypass a check. Policy changes become difficult to coordinate. The alternative is to separate policy decisions from framework-specific execution.

Each agent runtime integrates with an authoritative authorization service, while retaining responsibility for enforcing the decision at the actual tool boundary.

The critical requirement is that the runtime must not provide an alternate path around enforcement.

An independent policy service is not sufficient if tools can still execute without passing through the protected boundary.

9. Limitations

There are some deliberate limitations.

The lab does not introduce a new agent orchestration system.
It does not deploy applications, autonomously repair unauthorized changes, or guarantee that every downstream business constraint is satisfied.
It does not provide a replayable SQLite execution or demonstrate causal replay.
The evidence history is not a formally sealed ledger or a cryptographic attestation of the underlying database transaction.

Finally, the integrity binding of tool arguments protects the authorization relationship to the proposed operation. It does not replace business-level validation inside the application. These boundaries are important because AI governance should not become another collection of security claims that are difficult to verify.

10. Try Yourself

The implementation is publicly available.

Hands-on developer guide:

https://governance.bhanuj.ai/guides/langgraph-governed-operations

Open-source labs:

https://github.com/Bhanuj-AI/labs

BHANUJ-AIGP:

https://governance.bhanuj.ai

The developer guide walks through the LangGraph workflow, SQLite integration, identity configuration, policy setup, authoritative authorization path, failure scenarios, and execution evidence inspection.

The first read-only checkpoint requires no model API or paid cloud service. The authoritative authorization exercise additionally requires the local AIGP OSS service and appropriate identity and policy configuration.

Larger Engineering Question

As agents become capable of modifying production systems, the security boundary cannot depend solely on what the model believes it is allowed to do. The model may determine the next action. But the authority to execute that action should come from a trusted system outside the model's control. That is the principle this experiment explores.

I'm curious how other engineers are approaching this:

Should authorization for AI agent tool calls live inside the agent framework, at the tool boundary, or in an independent policy service?

And more importantly, how are you proving that unauthorized actions cannot bypass the enforcement mechanism?

I'm building BHANUJ-AIGP as an open-source project focused on AI governance, runtime authorization, execution evidence, and change assurance. This article describes one practical integration experiment and its current limitations.