Intent-Governed Tool Authorization for AI Agents

Overview

An integration may legitimately hold broad permissions while the user’s current request is narrow. If a user asks for a summary, the agent should not gain export or delete authority simply because those tools are available.

Intent-Governed Access Control turns the trusted user request into an auditable intent certificate, narrows the tools visible in the current session, and checks whether the selected tool, payload, resources, and expected effect remain within that certificate. Ambiguous, low-confidence, or high-risk cases can be denied, clarified, or routed to OpenPort’s draft and preflight controls.

Abstract

AI agents increasingly act through external tools: they read private data, construct structured payloads, submit write requests, export records, and coordinate workflows across application boundaries. Existing authorization mechanisms usually ask whether an integration credential, app, or token can call a tool. That question is necessary but incomplete. A tool call can be authorized by static credentials and still be unjustified by the user’s current request. For example, a credential that can read and export records should not expose export authority when the user only asked for a bounded summary, and a model-generated delete call should not execute merely because the integration has a delete scope. This paper proposes Intent-Governed Access Control (IGAC), a server-side authorization layer that treats the user’s expressed intent as a monotone, auditable policy attribute for AI-agent tool use. IGAC introduces intent certificates, session-scoped policy narrowing, intent-aware manifest filtering, and intent-tool-payload consistency checks. The central invariant is that user intent may only reduce the authority granted by static integration policy; it never expands scopes, data policy, tenant boundaries, or review requirements. We map IGAC onto OpenPort, an existing governance substrate that already implements authorization-dependent discovery, scope and ABAC-style policy checks, draft-first writes, preflight impact binding, state-witness checks, idempotency, stable reason codes, and audit. The current artifact includes a minimal reusable IGAC runtime path in OpenPort: an intent endpoint, in-memory certificate store, intent-aware manifest endpoint, intent-bound action/preflight checks, reason-code failures, and audit binding. We therefore present a formal model, security analysis, implementation mapping, executable synthetic checks, a runtime-backed microbenchmark, an expanded real-LLM pilot, a scored end-to-end LLM-in-the-loop runtime benchmark over the actual OpenPort path, and a benchmark-shaped external-subset runtime pilot. The deterministic checks validate internal policy invariants, while the provider-backed LLM studies provide preliminary runtime-path evidence of unsafe-execution containment and help characterize the remaining unsafe-accepted-authority surface. The paper positions intent as a missing access-control primitive between natural-language user requests and enforceable tool effects.

Core contributions

1. 01

   Problem formulation

   Identifies intent–tool mismatch as an access-control failure: a call may be allowed by static credentials but unsupported by the user’s current expressed request.

2. 02

   Formal model

   Defines intent certificates, monotone session-policy narrowing, intent-aware manifests, resource and effect bounds, consistency predicates, and auditable enforcement records.

3. 03

   Server-side design

   Filters visible tools and validates tool, payload, resource, and effect consistency without treating the model, planner, or intent classifier as the final security principal.

4. 04

   Reusable runtime path

   Maps IGAC onto OpenPort and implements a minimal path for certificate creation, intent-aware manifests, action and preflight checks, stable denial reasons, lifecycle isolation, and audit binding.

5. 05

   Preliminary evaluation

   Provides deterministic checks, a runtime-backed synthetic microbenchmark, real-LLM pilots, and small end-to-end runtime studies. These support mechanism-level findings, not deployment-level safety claims.

How IGAC builds on OpenPort

OpenPort answers: “May this integration produce this effect under standing policy?” IGAC adds: “Is this effect justified by what the user asked for now?”

OpenPort is the downstream effect-control substrate. IGAC is the upstream intent-control layer: it narrows visible tools and eligible effects before passing an allowed call into OpenPort’s governed execution path. IGAC cannot grant anything denied by OpenPort or the underlying authorization system.

1. 01User intent
2. 02Dynamic least privilege
3. 03Filtered tools
4. 04Governed effects

Cite this work

Use the DOI for a stable reference. The BibTeX record below identifies the arXiv version shown on this page.

Zhu, G., & Wang, C. (2026). Intent-Governed Tool Authorization for AI Agents [Preprint]. arXiv. https://doi.org/10.48550/arXiv.2606.22916

@misc{zhu2026igac,
  title         = {{Intent-Governed Tool Authorization for AI Agents}},
  author        = {Zhu, Genliang and Wang, Chu},
  year          = {2026},
  month         = jun,
  eprint        = {2606.22916},
  archivePrefix = {arXiv},
  primaryClass  = {cs.AI},
  doi           = {10.48550/arXiv.2606.22916},
  url           = {https://arxiv.org/abs/2606.22916},
  note          = {arXiv:2606.22916v1}
}