Tool authorization
Also called: agent tool permissions, six-layer tool authorization
Checking an agent's permission to invoke a specific capability, separately from its permission to read the underlying data.
What tool authorization means.
Tool authorization governs which capabilities an agent may invoke, evaluated independently of its data access. The separation matters because reading a record and modifying it are different privileges that a single credential often conflates. A tool authorization design can consider the agent, tool, parameters, target, principal, and context. Trunnion's implemented checks and test evidence are release-specific.
Why it matters.
Most agent incidents are not data exfiltration; they are unintended action. An agent that correctly reads a system and then writes to it, sends something externally, or triggers a downstream process has done something no data-access policy addressed. Authorizing tools separately, with parameter-level scrutiny, is what prevents a legitimate read from becoming an unintended write.
How it works in practice.
Distinct from data access
Permission to read a resource does not confer permission to invoke a tool that modifies it. The two decisions are evaluated separately.
Parameters are part of the check
A tool an agent may generally call can still be denied for a specific target or argument, so authorization is not all-or-nothing per tool.
Scoped to the step
In a multi-agent workflow each role carries only the tools its step needs, so the run never holds the union of every permission.
Invocations are recorded
Each call, its parameters, and the authorization decision are written to the audit trail as evidence.
What people get wrong.
That restricting the tool list is sufficient. Tool-level allowlists ignore parameters, and most consequential differences live there: the same send or update capability is routine against one target and serious against another.
Common questions.
Why authorize tools separately from data?
Because reading and acting are different risks. An agent may legitimately need to read a system of record while having no business modifying it. A single permission covering both makes the safe case impossible to express.
What are the six layers?
The checks cover the calling agent's identity and role, the tool being invoked, the parameters supplied, the target resource, the principal the agent is acting for, and the run context. Every layer must permit the call before it executes.
How does this relate to approval gates?
They are complementary. Tool authorization decides whether an action is permitted at all. An approval gate decides whether a permitted but consequential action should proceed now, and puts a named person on that decision.
Standards referenced.
Trunnion is engineered to align with these control families. Alignment by design is not a claim of current certification or authorization.
Read next.
- ABAC for AI agentsAccess control that evaluates attributes of the agent, the resource, and the context on every action, instead of granting a fixed role up front.
- Human-in-the-loop approval gateA checkpoint where an autonomous agent pauses and a named person approves, edits, or rejects a consequential action before it executes.
- Agent governanceThe control layer that decides what an AI agent may do, who approves consequential actions, and how every step is proven afterward.
Get started
See tool authorization running on your workflow.
Governance, approval, and provable audit built into the control plane, from cloud to air-gap. Request a demo against a workflow you actually run.