PaperlayerView exact revision on arXiv

Source-linked AI summary

Before the Tool Call: Deterministic Pre-Action Authorization for Autonomous AI Agents

Uchi Uchibeke

arXiv:2603.20953v1cs.CRcs.AI

TL;DR

AI agents lack a standard, deterministic mechanism to authorize individual tool calls before execution. The paper presents OAP, which intercepts calls at a framework-level hook and evaluates them against declarative policy. In the reported adversarial testbed, social-engineering success fell from 74.6% under permissive policy to 0% under restrictive OAP enforcement.

  • Problem

    AI agents lack standardized per-action authorization before tool execution, while existing alignment and evaluation approaches do not provide deterministic policy enforcement at that boundary.

  • Method

    OAP uses a framework-level blocking hook, declarative policies, and signed audit-oriented authorization infrastructure to decide whether each tool call may proceed.

  • Results

    74.6% of social-engineering attempts succeeded under permissive policy, versus 0% across 879 highest-tier attempts under restrictive deterministic policy enforcement.

  • Takeaways & Limitations

    Pre-action authorization is distinct from and complementary to alignment, evaluation, and sandboxing as an enforcement layer for agent actions.

  • Takeaways & Limitations

    OAP evaluates calls independently and does not yet formalize delegation chains, leaving aggregate sequence attacks and multi-agent delegation for planned extensions.

Abstract

from arXiv · show

AI agents today have passwords but no permission slips. They execute tool calls (fund transfers, database queries, shell commands, sub-agent delegation) with no standard mechanism to enforce authorization before the action executes. Current safety architectures rely on model alignment (probabilistic, training-time) and post-hoc evaluation (retrospective, batch). Neither provides deterministic, policy-based enforcement at the individual tool call level. We characterize this gap as the pre-action authorization problem and present the Open Agent Passport (OAP), an open specification and reference implementation that intercepts tool calls synchronously before execution, evaluates them against a declarative policy, and produces a cryptographically signed audit record. OAP enforces authorization decisions in a measured median of 53 ms (N=1,000). In a live adversarial testbed (4,437 authorization decisions across 1,151 sessions, $5,000 bounty), social engineering succeeded against the model 74.6% of the time under a permissive policy; under a restrictive OAP policy, a comparable population of attackers achieved a 0% success rate across 879 attempts. We distinguish pre-action authorization from sandboxed execution (contains blast radius but does not prevent unauthorized actions) and model-based screening (probabilistic), and show they are complementary. The same infrastructure that enforces security constraints (spending limits, capability scoping) also enforces quality gates, operational contracts, and compliance controls. The specification is released under Apache 2.0 (DOI: 10.5281/zenodo.18901596).

1 Introduction

AI agents can perform consequential tool calls, but current defenses place execution decisions in probabilistic model alignment or ad hoc application validation rather than a security-grade, declarative authorization layer. The paper frames this missing per-action mechanism as the pre-action authorization problem and presents OAP as its proposed solution.

  • The paper defines the gap between what agents can do and should do as a pre-action authorization problem distinct from alignment.
  • Tool calls let agents transfer funds, query databases, execute code, communicate, and delegate tasks across production environments.
  • Current execution decisions rely on model alignment or application-layer input validation, neither of which provides declarative policy enforcement or verifiable audit records.
  • The paper contributes an open specification for pre-action authorization with a formal threat model and authorization function.
  • The paper evaluates OAP through adversarial decisions, attack sessions, production benchmarks, and mappings to established AI-security frameworks.

2 Background and Related Work

Related work spans probabilistic alignment and screening, retrospective evaluation, sandboxed execution, deterministic runtime policy enforcement, identity infrastructure, and agent-security standards. OAP is positioned as a complementary per-action authorization layer rather than a replacement for these approaches.

  • Training-time alignment shifts model behavior probabilistically, while post-hoc evaluation identifies patterns after completed runs rather than intercepting production tool calls.
  • Sandboxed execution contains effects through isolation but does not enforce semantic business policies, provide per-action authorization trails, or prevent malicious parameters within permitted scope.
  • Runtime policy systems differ in enforcement mechanism: PCAS uses a Datalog-derived reference monitor, while AgentGuardian learns adaptive policies and trades determinism for adaptability.
  • Model-based pre-execution screening intervenes before actions but remains vulnerable to classifier manipulation and adversarial inputs.
  • Identity systems identify agents or workloads, whereas OAP authorizes permitted actions per call and can complement OAuth or SPIFFE credentials.
  • A2A requires authorization before sensitive actions but leaves the mechanism unspecified, while its Secure Passport Extension shares contextual state rather than enforcing per-action policy.

3 The Open Agent Passport (OAP)

OAP combines signed agent passports, declarative policy packs, and a blocking before_tool_call hook to authorize tool calls before execution. Its design supports scoped capabilities, contextual constraints, assurance levels, and framework-level enforcement.

  • 3.3 The Agent Passport: An agent passport is a signed credential binding an agent’s identity to its authorized capability scope.
  • 3.3 The Agent Passport: The reference implementation verifies registry-issued Ed25519 signatures on every tool call and returns structured denial codes for out-of-scope capabilities or exceeded limits.
  • 3.4 Policy Packs: A policy pack declaratively specifies required JSON-Schema context, condition–deny_code rules, and minimum assurance requirements for a capability domain.
  • 3.4 Policy Packs: Policy evaluation is restricted to finite comparisons and set membership, ensuring termination in O(n) time for the number of matched rules.
  • 3.5 The before_tool_call Hook: The before_tool_call hook blocks execution until a policy decision returns, regardless of whether frameworks implement it synchronously or asynchronously.
  • 3.5 The before_tool_call Hook: The hook operates at the framework or platform level, so prompt injection that induces a tool request does not bypass the policy check.
  • 3.6 Assurance Level Taxonomy: OAP defines six assurance levels that map enforcement strength to verification rigor.

4 Formal Characterization

OAP formalizes pre-action authorization as deterministic policy evaluation over agent passports and tool calls, with fail-closed, non-bypassable, and auditable decisions. Its guarantees depend on trusted runtime behavior, while restricted policies trade expressiveness for decidable linear-time evaluation.

  • 4.1 Threat Model: The attacker model includes prompt injection, compromised sub-agents, obtained credentials, and parameter manipulation within authorized capabilities.These threats target both agent context and tool-call parameters.
  • 4.1 Threat Model: OAP defends against unauthorized calls, privilege escalation, policy-violating actions, and parameters exceeding declared limits.It does not defend against unintended side effects within authorized scope, content-level attacks, compromised runtimes, side channels, or kernel exploits.
  • 4.2 The Authorization Function: The authorization function maps a tool call, passport, and policy pack to ALLOW, DENY, or ESCALATE and records the decision in a signed audit entry.The passport contains identity, capabilities, limits, and assurance level; the log includes agent, tool, parameters, decision, timestamp, and Ed25519 signature.
  • 4.2 The Authorization Function: OAP requires deterministic, complete, fail-closed, non-bypassable, and auditable authorization decisions.Invalid passports, unavailable policies, or other fail-closed conditions produce DENY, and tool execution requires ALLOW.
  • 4.4 Property Analysis: Under the stated trust assumptions, Algorithm 1 satisfies the five authorization properties.The proposition relies on trusted framework hook invocation, deterministic policy evaluation, and uncompromised signing infrastructure.
  • 4.4 Property Analysis: Non-bypassability is conditioned on platform trust because the algorithm alone cannot prove that the framework invokes the blocking hook.TEE-based attestation is identified as a possible way to strengthen this assumption.
  • 4.4 Property Analysis: Policies use finite comparisons and set membership without loops, recursion, or external state, ensuring termination in O(n) time for n matched rules.OAP trades expressiveness for guaranteed constant-time evaluation per rule.
  • 4.4 Property Analysis: Pre-action authorization is distinct from model alignment, post-hoc evaluation, and sandboxing, which address different runtime-safety properties.Sandboxing contains blast radius but does not prevent execution within the sandbox or enforce semantic business rules.

5 Three Architectures for Runtime Agent Safety

Runtime agent safety architectures operate at different layers and address different failure classes, so production deployments require complementary controls. Pre-action authorization blocks policy-violating calls, sandboxing contains execution, and model screening assesses potentially malicious intent probabilistically.

  • Taxonomy: The taxonomy separates three runtime safety architectures by layer, failure class, and the failures each leaves uncovered.No single architecture covers all dimensions.
  • Complementarity: Production deployment requires pre-action authorization and sandboxed execution, while model-based screening adds defense-in-depth for adversarial intent classification.The paper presents these architectures as complementary rather than competing.
  • Sandboxed Execution: Sandboxed systems can block resource- or network-level actions but cannot enforce semantic rules such as spending limits or recipient allowlists.Those rules require organizational-policy knowledge rather than only resource isolation.
  • Model-Based Screening: Deterministic decoding can make screening outputs reproducible, but the learned decision boundary can still shift under adversarial inputs.This distinguishes model screening from static policy evaluation.
  • Worked Examples: For a prompt-injected /etc/passwd read, OAP denies the call before execution, sandboxing blocks it after the attempt reaches the environment, and screening may or may not flag it.The example contrasts policy enforcement, containment, and probabilistic intent classification.
  • Worked Examples: For a $500 charge exceeding policy, OAP denies execution, whereas sandboxing may allow the network call and screening may see no malicious pattern.The example shows why resource containment and intent screening do not replace semantic spending controls.

6 Evaluation

OAP was evaluated in an adversarial banking testbed and production latency benchmarks. Restrictive per-action policies blocked unauthorized transfers deterministically, while authorization added low latency and covered most listed OWASP agentic risks.

  • Adversarial Testbed: The Vault testbed combines a frontier language model for conversation with an OAP policy engine that evaluates authorization deterministically from signed passports.Participants attempted to manipulate a banking agent into making unauthorized transfers through social engineering.
  • Adversarial Testbed: 74.6% of social engineering attempts succeeded under T1’s permissive policy, whereas 0% succeeded under T5’s restrictive capability-scoping policy.T1 used wildcard merchants and high limits; T5 used zero capabilities and a $0 limit.
  • Adversarial Testbed: 173 evaluation_error denials (7.1% of all denials) were deterministic responses to malformed or incomplete tool-call contexts.These failures were input-validation failures at the policy boundary, not evaluation-engine non-determinism.
  • Performance Benchmarks: Cloud API authorization had a median latency of 53 ms, with p99 below 77 ms across configurations.The benchmark used N=1,000 requests per mode; local evaluation had a 174 ms median because of Python subprocess overhead.
  • Risk Coverage: OAP provides full or partial coverage for 8 of 10 OWASP Agentic risks.Improper Output Handling and Knowledge Poisoning remain content-layer risks outside OAP’s coverage.

7 Standards Alignment

The paper proposes pre-action authorization as a distinct standards control category. Its requirements cover machine-readable policies, synchronous platform enforcement, verifiable agent credentials, and tamper-evident authorization logs.

  • Proposed Control Category: The proposed PAA category treats pre-action authorization as a distinct control for AI-agent tool calls.The proposal is positioned as a standards contribution alongside mappings to NIST AI RMF and SP 800-53.
  • PAA Requirements: PAA-1 requires a machine-readable authorization policy specifying permitted tool calls, conditions, and assurance levels.The requirement makes authorization constraints explicit and machine-readable.
  • PAA Requirements: PAA-2 requires synchronous, platform-level enforcement before each tool call, independent of model reasoning.The control targets the execution boundary rather than relying on the model’s decision process.

8 Discussion

The discussion frames OAP as one layer in a broader safety architecture while identifying boundaries in delegation, expressiveness, adaptation, scale, trust, and aggregate-call reasoning. It also extends the infrastructure’s role from security enforcement to accountability controls.

  • Limitations: OAP v1.0 does not formalize delegation chains for multi-agent scenarios; narrowed sub-agent permissions are planned for v1.1.The missing delegation model is a stated version boundary.
  • Limitations: OAP’s declarative JSON/YAML policies are easier to author and audit than Datalog-derived policies but support less expressive conditional logic.Complex conjunctions may require policy composition or language extension.
  • Limitations: OAP policies are static and must be authored or updated manually, unlike learned policies that can adapt to novel attack patterns.The paper identifies a hybrid static-policy and learned-anomaly approach as a natural extension.
  • Limitations: OAP governs tool-call boundaries, leaving direct output rendering, in-context retrieval, and side-channel communication out of scope.The paper identifies sandboxed execution as the complementary containment layer for those cases.
  • Limitations: Because OAP evaluates calls independently, individually permitted calls can collectively produce unauthorized outcomes such as aggregate-transfer structuring.The v1.1 draft proposes sliding-window policy packs with per-agent aggregate state.
  • Full Safety Stack: A production safety architecture combines model alignment, pre-action authorization, sandboxed execution, and post-hoc evaluation because each layer addresses a different gap.The paper states that removing any one layer leaves a structural gap.
  • Accountability: The same identity, policy, and cryptographic infrastructure can encode quality gates, operational contracts, and compliance controls in addition to security constraints.Examples include minimum test coverage, SLA requirements, and data-residency conditions.

9 Conclusion

The paper frames standardized pre-action authorization as the missing access-control layer for autonomous agents and presents OAP as an open implementation of that layer. OAP complements alignment, evaluation, and sandboxing, while remaining subject to formalization, expressiveness, scale, and implementation limits.

  • 9 Conclusion: 27.2% of engineering teams building agents use custom authorization from scratch, while 492+ MCP servers lack authentication and agents have leaked SSNs through single-verb reframing.These findings are presented as evidence that the authorization gap is operationally real.
  • 9 Conclusion: 4,437 adversarial decisions across 1,151 sessions found 74.6% social-engineering success when the model was the primary defense, versus 0% across 879 attempts under deterministic policy enforcement.The adversarial testbed included a $5,000 prize.
  • 9 Conclusion: Pre-action authorization is distinct from alignment, evaluation, and sandboxed execution, and the paper presents the architectures as complementary.The conclusion distinguishes the authorization layer rather than positioning it as a replacement for the other approaches.
  • 9 Conclusion: OAP is an open-source, specification-first implementation deployed across six agent frameworks and evaluated against live adversarial attacks.One additional framework integration is proposed.
  • 9 Conclusion: OAP does not yet formalize delegation chains, supports bounded declarative JSON policy expressiveness, has modest-scale benchmarks, and leaves ESCALATE unimplemented.The paper identifies enterprise-scale validation at 10,000+ evaluations/second as still needed.

Disclosure

The author discloses founding APort Technologies Inc., which develops and operates the evaluated OAP reference implementation.

  • Disclosure: The author is the founder of APort Technologies Inc., which develops and operates the OAP reference implementation evaluated in this paper.The specification is released under Apache 2.0 and the artifacts are publicly available.

A Artifacts and Reproducibility

The paper makes its artifacts and reproduction procedures publicly available, covering performance benchmarks, CTF results, specification artifacts, standards mappings, and structured authorization denials.

  • A Artifacts and Reproducibility: All artifacts required to reproduce the paper's results are publicly available under Apache 2.0.The paper separates reproduction resources for performance benchmarks and CTF results.
  • A Artifacts and Reproducibility: The paper provides specification artifacts and mappings to the NIST AI RMF and NIST SP 800-53.The supplied artifacts include Tables 11–13 for specification artifacts, NIST AI RMF mapping, and NIST SP 800-53 alignment.
  • A Artifacts and Reproducibility: Performance benchmarks can be reproduced with the published agent-guardrails package, a passport, and policy-verification requests measured at N=1,000.The procedure specifies installing @aporthq/aport-agent-guardrails v1.0.15 and timing POST /api/verify/policy/{capability_id}.
  • A Artifacts and Reproducibility: A DENY response includes a decision, deny code, reason, decision ID, and Ed25519 signature.The example reason reports that an amount exceeded a max_per_tx limit.
  • A Artifacts and Reproducibility: Agent frameworks can use structured denial codes to generate contextual user responses without exposing internal policy details.The example uses oap.merchant_forbidden to explain that a recipient is not on the approved list.
Loading 2603.20953v1…