AIG-042 Agentic Tool Permissions and Action Authorisation
Description
Each AI agent able to invoke tools or take actions beyond its own inference holds a named permission set listing the tools it may call and the scope of each call. The permission set is enforced by the system, not described in a prompt. A grant record for each permission names who requested it, who approved it, the task it was granted for and its expiry. Actions the organisation has classified as consequential carry a recorded human approval before they execute, identifying the person, the action and the parameters approved. Every tool invocation is recorded with the agent identity, the session or task identifier, the tool called, the parameters passed, the authorisation that permitted it and the outcome. A permission is revocable while the agent is running and the revocation takes effect on the next invocation. Where an agent acts for a named user, the permission set in force for that run is bounded by the authorisations that user holds, so a call the user could not make is refused. A tool an agent invokes executes under that agent's identity and restrictions rather than under a standing credential of its own. A sub-agent or a delegated task inherits the parent's constraints and holds a scope equal to or narrower than the parent's, never wider.
Rationale
Three controls sit around this one and answer different questions. AIG-029 asks whether an attacker can make the agent act and answers with injection testing, instruction and data separation and a sandbox. APP-016 asks what the code an agent runs can do to its host. AIG-042 asks what the agent is allowed to do when nothing has gone wrong: which tools, at what scope, granted by whom, approved by whom for the consequential ones and withdrawable when the answer changes. An agent with a sound sandbox and a sound injection defence can still transfer funds to the wrong account if nobody scoped the payments tool. AIG-020 records what an AI system did, tool calls included; AIG-042 requires the authorisation that permitted the call to be part of that record, which is the field that makes an action log answerable after the fact. IAM-010 governs the identity the agent authenticates as and IAM-005 the least-privilege principle the scopes apply; AIG-042 is the delegation layer above them, where a person's authority is lent to a process acting on their behalf. Which actions count as consequential is a recorded classification, usually turning on irreversibility, spend, access to personal data, communication outside the organisation and change to production. The agentic action-authorisation vocabulary arrives with the OWASP extraction in S5 and this control is where it lands, so the mappings here are expected to firm up then. Both seats (ADR-031). IAM-010 governs the identity an agent authenticates as and the lifecycle of that identity, including revocation when it is no longer used. AIG-042 governs the authority carried into it for a run, which is the delegated half of the same question: an agent inside its own permission set can still act with authority the requesting user does not hold. What the agent remembers between runs and whether that memory can be trusted are AIG-056; this control governs what it may do.
Applicability (9 profiles)
Permission sets, approval of consequential actions and invocation logs for agents the deployer runs against its own systems are its own. Where the agent runtime is the provider's, enforcement is a provider feature and the deployer configures and records the grants.
Permission sets, approval of consequential actions and invocation logs for agents the deployer runs against its own systems are its own. Where the agent runtime is the provider's, enforcement is a provider feature and the deployer configures and records the grants.
Framework Mappings (30)
| AIS-11 | Agents Security Boundaries | full |
| IAM-05 | Least Privilege | informative |
| IAM-15 | Authorization Mechanisms | partial |
| IAM-16 | Knowledge Access Control - Need to Know | informative |
| IAM-18 | Agent Access Restriction | full |
| IAM-05 | Least Privilege | informative |
| IAM-15 | Authorization Mechanisms | partial |
| A.6.2.8 | AI system recording of event logs | informative |
| AML.M0024 | AI Telemetry Logging | informative |
| AML.M0026 | Privileged AI Agent Permissions Configuration | full |
| AML.M0027 | Single-User AI Agent Permissions Configuration | partial |
| AML.M0028 | AI Agent Tools Permissions Configuration | full |
| AML.M0029 | Human In-the-Loop for AI Agent Actions | full |
| AML.M0030 | Restrict AI Agent Tool Invocation on Untrusted Data | informative |
| AML.M0037 | AI Agent Authority Expansion Controls | partial |
| AC-3 | Access Enforcement | partial |
| AC-6 | Least Privilege | informative |
| AC-6(9) | Least Privilege | Log Use of Privileged Functions | informative |
| AU-12 | Audit Record Generation | informative |
| AU-2 | Event Logging | informative |
| MS-2.7-001 | AI System Security and Resilience Evaluation | MS-2.7-001 | informative |
| MANAGE 2.4 | AI System Deactivation and Override Mechanisms | informative |
| ASI01 | Agent Goal Hijack | informative |
| ASI02 | Tool Misuse and Exploitation | full |
| ASI03 | Identity and Privilege Abuse | full |
| ASI05 | Unexpected Code Execution (RCE) | informative |
| ASI10 | Rogue Agents | partial |
| LLM01 | Prompt Injection | informative |
| LLM03 | Excessive Agency | full |
| LLM08 | Hidden Context Exposure | informative |
Evidence (3)
The permission set for each agent, read from the running system or from the infrastructure code that defines it, listing the tools it may call and the scope of each call. Where agents act for named users, the configuration also shows how a run's scope is bounded by the requesting user's authorisations and how a sub-agent's scope is derived from its parent's.
Example: Agent permission manifests under infra/agents/ at commit 9ac31b7, with the runtime scope listing fetched from the orchestrator on 2 July 2026.
Test: Verify: (1) every agent in the inventory has a permission set defined outside its prompt, (2) the scopes held at runtime match the scopes in the grant record, with no additional tool reachable, (3) no permission is past the expiry its grant record states, (4) removing a permission in the defining system stops the next invocation of that tool rather than the next restart. (5) a run started on behalf of a test user whose authorisations exclude one tool in the agent's permission set is refused that tool, (6) a sub-agent spawned inside that run holds a scope equal to or narrower than its parent's, (7) a tool called by two agents with different restrictions executes under each caller's restrictions rather than under one standing credential.
Tool invocation log carrying the agent identity, the session or task identifier, the tool called, the parameters passed, the authorisation that permitted the call and the outcome.
Example: Orchestrator invocation log for 1 to 30 June 2026, queried for the payments and outbound messaging tools.
Test: Verify: (1) every invocation carries all six fields the control names, (2) no invocation resolves to an authorisation that was expired or revoked at the time of the call, (3) every invocation of a tool classified as consequential resolves to an approval record identifying a person, (4) sampling an approval and re-reading the invocation shows the parameters executed matching the parameters approved.
The grant register and the classification of consequential actions, showing for each permission who requested it, who approved it, the task it was granted for and its expiry, together with the statement of which action types require human approval.
Example: Agent permission grant register, extract of 30 June 2026, with the consequential action classification version 2 of 4 March 2026.
Test: Verify: (1) every permission in the running configuration appears in the grant register, (2) the requester and the approver are different people, (3) the classification states the basis on which an action type is consequential rather than listing types alone, (4) a permission whose expiry has passed appears in the register as renewed or as removed from the configuration.
Questions (3)
Does each AI agent that can invoke tools hold a permission set enforced by the system rather than described in its prompt?
A prompt instruction telling an agent which tools to use is not an enforced permission set. Answer yes only where the orchestrator or the tool layer refuses a call outside the set. Where you run no agents that invoke tools, this control does not apply to you.
Which of the following are in place for agent tool permissions?
Options follow the path from grant to invocation and then to delegation. The scope item asks whether a permission to call a tool is bounded, for example to one account, one repository or one spend limit, rather than being a permission to call it for anything. The last three items are about borrowed authority: an agent acting for a user, a shared tool and a sub-agent are the three places an authority quietly widens.
What happens when an agent attempts an action classified as consequential?
Options run from the strongest gate to the weakest. Answer for the behaviour of the system in production, not for the behaviour a configuration flag could produce.