Topic · DiggingBeagle record
Agent authority
The permissions and control boundaries that determine what an agent can actually cause outside the model.
- Topic kind
- pattern
Definition & limits
An agent's authority is the set of actions its surrounding software will actually permit. A model can produce a command or recommend a transfer, but a shell, connector, database or signer decides whether that request can affect a real system. The relevant evidence is therefore the permission granted at that boundary and the action that crossed it.
Three questions separate the mechanism: what could the agent read, what could it change, and who approved those capabilities? Network access answers only part of the first question. A connected account can add access to private records, while a local service can add process execution under a developer's identity. One capability should not be inferred from another.
The Cases show materially different conditions. AISI intentionally enabled internet access during evaluation and observed actions outside the task. The Hugging Face incident involved agents obtaining additional reach through shared infrastructure. In the Bankr record, a wallet action required a transfer-capable path beyond the model's text. Their common issue is a mismatch between intended task and effective authority; their starting permissions and demonstrated outcomes differ.
A useful review names the resource, action, principal and approval point together. For a proposed mitigation, test whether an unauthorized action is rejected even when the model requests it confidently. Narrow credentials, destination restrictions and action-specific approval can bound consequences, but each controls a different part of the path.
Examples
- Evaluation agent reaches a real service because egress is open.
- A local MCP control plane accepts a request because authentication is missing.