Per-tool authorization middleware for agent tool calls

[webpro255]

Please read this first

• Have you read the docs? Yes
• Have you searched for related issues? Yes. Found no existing issue for per-tool authorization middleware in this SDK.

Describe the feature

The SDK has guardrails for input/output validation and human-in-the-loop for approval flows. What's missing is a per-tool authorization layer that evaluates whether a tool call should execute based on identity, scope, rate limits, and session context.

Guardrails check content. Authorization checks permission. Both are needed but they solve different problems.

Example: An agent with access to send_email and query_database passes every guardrail check but uses those tools to exfiltrate customer data to an external address. The content looks normal. The authorization was never checked.

Proposed solution: A per-tool authorization middleware that intercepts tool calls before execution:

• Evaluate each tool call against identity, role, scope, and session state
• Support non-binary decisions: ALLOW, DENY, MODIFY, DEFER, STEP_UP
• Generate structured audit records for every decision
• Non-invasive: existing tools work without code changes

I'm the creator of AgentLock (Apache 2.0), an open authorization standard for AI agent tool calls. Happy to build an "openai-agentlock" integration as a separate PyPI package if that's the preferred approach.

Benchmark: 99.5/A against 222 adversarial attack vectors across 35 categories.

GitHub: github.com/webpro255/agentlock

[aeoess]

The distinction you're drawing — guardrails check content, authorization checks permission — is the right decomposition. The email exfiltration example makes it concrete: the content is benign, the authorization was never evaluated.

Agent Passport System provides the per-tool authorization layer you're describing:

import { createActionIntent, evaluateIntent, completeAction } from 'agent-passport-system';

// Before tool execution: declare what you want to do
const intent = createActionIntent(agent, {
  scope: 'email:send',
  target: 'external-address@example.com',
  action: 'send_email'
});

// Policy engine checks: does this agent's delegation allow email:send?
// Is the target on the merchant/recipient allowlist?
// Has the rate limit been exceeded?
const evaluation = evaluateIntent(intent, delegation, valuesFloor);
// → { permitted: false, reason: "scope email:send not in delegation [query:database]" }

The evaluation checks identity (valid passport), scope (delegation includes email:send), rate limits (per-action and cumulative), and session context (delegation hasn't expired or been revoked). All four of your criteria.

Key architectural point: the policy evaluation is a separate signer in a 3-signature chain. The agent declares intent, the policy engine signs the evaluation, the agent signs the execution receipt. The agent cannot forge or skip the authorization step because it doesn't hold the policy engine's key.

This works as middleware — the governedToolCall() adapter wraps any tool call function and returns deny before execution reaches the tool if authorization fails.

npm: agent-passport-system · 103 modules, Apache-2.0

[webpro255]

Thanks for sharing. Agent Passport System looks like a TypeScript implementation. AgentLock is Python-native and framework-agnostic, designed to sit at the tool call layer in Python agent frameworks like this SDK, LangChain, and CrewAI. Different ecosystems, same problem space.

[aeoess]

We publish a Python SDK on PyPI: pip install agent-passport-system. The TypeScript SDK is the reference implementation but the protocol is language-agnostic. The Python package covers passport issuance, delegation creation and verification, intent evaluation, and receipt signing.

[Jairooh]

This distinction between guardrails and authorization is exactly right. One critical detail: effective authorization needs full run context—you might allow send_email alone, but deny it if the agent just exfiltrated data via query_database in the same session. Your ALLOW/DENY/MODIFY/DEFER/STEP_UP model handles this well. Also essential: every decision needs structured audit logging (identity, policy, cost, risk)—that's how you catch patterns across the full agent lifecycle.

[webpro255]

Exactly. Per-call evaluation misses session-level patterns. AgentLock tracks this with compound signal scoring: if query_database fires followed by send_email in the same session, the combo detector raises the session risk score and the gate can DEFER or STEP_UP the send_email call even though both tools are individually authorized. Session risk is monotonic, never decreases within a session.

On audit: every decision (all 5 types) produces a structured record with identity, role, tool, parameters hash, decision reason, risk score, and hardening state. v1.2.1 adds Ed25519 signed receipts so decisions are cryptographically verifiable offline.

[aeoess]

@webpro255 — the session-level compound signal scoring is the right extension of per-call evaluation. The monotonic session risk (never decreases within a session) is the same structural property as the sensitivity ratchet in crewAI#5262 — once the session risk score rises from a suspicious pattern, it can't be reset by a sequence of normal calls. That prevents a pattern where an attacker interleaves malicious and benign calls to keep the average score below threshold.

One composition point: the session risk model and the delegation model answer different questions and both need to be evaluated. Session risk says "the pattern of calls in this session is suspicious." Delegation says "this specific call is within the agent's authorized scope." An agent can be within delegation scope on every individual call and still show a suspicious session pattern (exfiltration via individually-authorized but collectively-dangerous calls). Both checks should produce signed decisions that chain — the delegation permit and the session risk score are independent evidence in the audit trail.

APS processToolCall handles the delegation check per call. A session-risk evaluator like AgentLock can ride as an additional policy dimension on the same hook. The composition is AND: both must permit for the call to proceed, either can deny independently. The signed receipt carries both decisions so post-hoc analysis can see which gate was active.

On the Ed25519 signed receipts in AgentLock v1.2.1 — if those receipts use JCS canonicalization for the signed payload, they're structurally interoperable with APS receipt chains. Worth verifying the canonicalization format so cross-system receipt verification is possible without adapter code.

[tomjwxf]

This is a real need. The current Guardrail interface works well for input/output validation, but per-tool authorization is a different problem: you need to evaluate the specific tool being called, its arguments, and the caller's permissions before execution, not just inspect the input/output.
One pattern that works well here is policy-based authorization using Cedar (from AWS). The tool call becomes a Cedar authorization request:

from agents import Agent, Runner
from agents.tool import FunctionTool
class ToolAuthMiddleware:
    """Wraps tool execution with Cedar policy evaluation."""
    def __init__(self, policy_set, principal_id):
        self.policy_set = policy_set
        self.principal = principal_id
    async def authorize_and_run(self, tool: FunctionTool, args: dict):
        # Build Cedar authorization request
        decision = self.policy_set.is_authorized(
            principal=f'User::"{self.principal}"',
            action=f'Action::"{tool.name}"',
            resource=f'Tool::"{tool.name}"',
            context=args  # tool arguments become policy context
        )
        if not decision.is_allowed():
            raise PermissionError(
                f"Policy denied: {tool.name} for {self.principal}"
            )
        return await tool.run(args)
The Cedar policy itself is declarative:

cedar
// Allow read-only tools for all users
permit(
    principal,
    action in [Action::"web_search", Action::"read_file"],
    resource
);
// Restrict destructive tools to admin
permit(
    principal == User::"admin",
    action in [Action::"delete_file", Action::"send_email"],
    resource
);
This separates the authorization logic from the agent code entirely. Policies can be updated without redeploying the agent, and the policy evaluation result can be logged as a signed receipt for audit.

I have a working WASM build of the Cedar policy engine ([PR #64 on cedar-for-agents](https://github.com/cedar-policy/cedar-for-agents/pull/64)) that could eventually run policy evaluation client-side in a browser or edge function, which fits the Agents SDK's lightweight philosophy.

If there is interest, I would be happy to put together a more complete example showing this pattern integrated with the Agents SDK guardrail system.

---
## 3. OpenAI Agents -- Comment on #2775
**URL**: https://github.com/openai/openai-agents-python/issues/2775
**Comment**:
Good thread. One dimension worth adding: guardrails and governance serve two different functions, and the SDK's current guardrail system handles one well but not the other.

Guardrails = prevention. "Stop the agent from doing X." The SDK's InputGuardrail and OutputGuardrail are well-designed for this.

Governance = evidence. "Prove the agent did Y, and only Y." This is what regulated environments need for compliance, and it is a harder problem because you need a tamper-evident record that survives after the agent run completes.

The practical pattern is: wrap the Runner lifecycle hooks to emit signed receipts for each tool call and handoff. Each receipt contains a hash of the inputs, outputs, and the policy that authorized the action. Chain the receipts (each receipt includes the hash of the previous one) and you get a tamper-evident execution log.

The SDK's tracing system is close to this, but tracing is observability (mutable, internal), not governance (immutable, verifiable by third parties).

I built this pattern for DeerFlow's LangGraph callbacks ([implementation here](https://github.com/tomjwxf/ScopeBlindD2/tree/main/examples/deerflow-receipts/receipt_middleware.py)). The same approach maps onto the Agents SDK's lifecycle hooks. The key design choice is where signing happens: in-process (simpler, lower latency) vs. external signer (better key isolation).

---
All three are ready to paste. Post the **Visa TAP issue first** (highest enterprise signal), then the two OpenAI comments. Let me know once they're up and I'll also get the aeoess vocabulary reply posted.

[pshkv]

@tomjwxf — Cedar fits well as the policy language layer. The authorization request shape you described (principal=agent, action=tool_call, resource=tool_name, context=args+session) maps directly to SINT's capability token check:

# Cedar authorization request
principal = AgentPrincipal(did=f"did:key:{agent_pubkey}")
action     = Action("tool_call")
resource   = Resource(f"mcp://{server}/{tool_name}")
context    = Context(args=tool_args, session_risk=session.risk_score, depth=token.delegation_depth)

# SINT equivalent (already shipped, Python SDK)
from sint_sdk import SintClient, SintRequest

decision = await client.intercept(SintRequest(
    agent_id=agent_pubkey_hex,
    token_id=capability_token.id,
    resource=f"mcp://{server}/{tool_name}",
    action="call",
    params=tool_args
))
# decision.action: "allow" | "deny" | "escalate"
# decision.assigned_tier: T0 | T1 | T2 | T3

On @Jairooh and @webpro255's session compound scoring: SINT has this at the protocol level via ProactiveEscalationEngine — tracks CSML (Composite Safety-Model Latency) across a configurable window. The query_database → send_email pattern triggers tier escalation because the CSML score for the combination exceeds the T1 threshold. webpro255's monotonic session risk (never decreases within session) is the right model — SINT's MemoryIntegrityPlugin implements the same invariant.

The difference from Cedar standalone: SINT adds the tier escalation layer on top of allow/deny — so send_email after query_database doesn't just get denied, it gets escalate with a structured reason code (COMPOUND_PATTERN_DETECTED), which the orchestrator can route to a human approval flow rather than hard-failing. That distinction matters for agent UX (deny = error, escalate = human checkpoint).

Python adapter: sdks/python/sint_sdk/adapters/openai_agents.py — wraps the OpenAI Agents SDK's tool call path in PolicyGateway.intercept(). ~40 lines, already shipped. Can integrate Cedar policies as a SafetyPermitPlugin — an async resolver that runs Cedar evaluation before the tier decision.

[VladUZH]

@tomjwxf — Cedar maps cleanly to this problem. One thing worth building in from the start: compliance labels on policy outcomes, not just allow/deny.

For regulated industries, auditors need to see which rule justified each decision, not just the binary result. We built this into SidClaw — each policy rule carries a regulatory clause reference (FINRA 2026, EU AI Act Article 12) that flows into the hash-chained audit trail. Turns "send_email was denied" into evidence that can satisfy a compliance review, not just an internal log entry.

pip install sidclaw / npm i @sidclaw/sdk if anyone wants to compare integration patterns.

[webpro255]

Built it.

pip install openai-agentlock

Wraps FunctionTool with per-call authorization through AuthorizationGate. Denials return to the model as strings, allowed calls get single-use tokens with session-level risk scoring.

GitHub: https://github.com/webpro255/openai-agentlock

Apache 2.0.