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:
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.
Top comments (0)