Permission Model
A permission model is the set of rules that determines what an actor is allowed to do — which resources it may read or change, which actions it may take and under whose authority. For an AI agent, the permission model answers practical questions: may it read the whole disk or one project folder, send email or only draft it, call a payments API or merely view invoices, and which of these require a human to say yes first. Because a language model's behavior cannot be guaranteed, the permission model is the layer that bounds the damage of any single mistake or manipulation, whatever the model decides to attempt.
The foundational idea is least privilege, stated by Saltzer and Schroeder in their 1975 paper on the protection of information in computer systems. Every program and user should operate with the minimum set of rights needed for the job, so that a failure or compromise exposes as little as possible. Applied to agents, this means a coding agent gets read and write access to one repository rather than the whole machine, a scheduling agent gets calendar scope without access to mail, and a research agent gets read-only web access. It is easy to state and tedious to implement, because defaults tend to drift toward convenience: a broad personal access token or an admin credential is quicker to set up than several narrow ones.
Scoped, short-lived tokens are the standard mechanism for delegation. Protocols such as OAuth 2.0 let a user grant an application named scopes, such as read-only access to files, instead of handing over a password, and cloud platforms issue temporary credentials that expire in minutes or hours. An agent should receive tokens narrowed by resource, action and time, held by the surrounding system rather than pasted into the model's context, so that a prompt-injected agent cannot simply read and repeat them. Audit logs on every use, separate identities for agents so that their actions are distinguishable from the user's, and quick revocation turn the permission model from a policy document into an enforceable and observable control.
Capability-based security offers a cleaner conceptual foundation than lists of who may do what. In access-control-list systems a program acts with the full authority of the user running it and each resource checks an identity against a list; in capability systems, introduced in the 1960s by Dennis and Van Horn, authority travels with an unforgeable reference to a specific object, and a program can only act on what it was explicitly handed. This avoids the confused deputy problem described by Norm Hardy in 1988, in which a trusted program is tricked into using its own broad authority on behalf of a less privileged caller. An agent is a confused deputy in waiting: it holds the user's authority and reads text from strangers, so an injected instruction can ask it to use rights the stranger never had. Passing the agent only the specific file handle, calendar or repository it needs follows the capability pattern even where the underlying system is not formally one.
User approval prompts are the human-facing layer, and they work only when used sparingly. Agent tools commonly separate actions into allowed without asking, such as reading files, and those that prompt, such as running unfamiliar shell commands, deleting data, spending money or sending messages, and many offer modes that let users pre-approve narrow patterns. Prompts help because they place a person at the moment of irreversible consequence; they fail through approval fatigue, when frequent identical requests train reflexive confirmation, and through vague wording that hides what is being approved. Good prompts name the exact action and target, appear only for genuinely consequential steps and are backed by hard limits that no click can override. Simon Willison's "lethal trifecta" framing from 2025 is a useful design test: an agent that combines access to private data, exposure to untrusted content and the ability to communicate externally is dangerous, so a permission model should ensure that all three are never available together without a human gate.
Common misconceptions are that instructions in the prompt can serve as permissions and that a model's refusal is an access control. Telling a model never to touch certain files is a request, not an enforcement, and a persuasive or injected input can talk it out of that request; real permissions must be enforced outside the model, in the tool layer, credentials and operating system. Another pitfall is granting broad rights because the task is trusted: the agent itself may be reliable while its inputs are not. Permissions also interact with sandboxing, which limits the environment, and with kill switches, which revoke access, so the three form a layered defense in which none is expected to carry the whole load.
Read permission model as the written-down answer to who may do what with whose authority: least privilege and scoped tokens shrink what any one mistake can reach, capability thinking prevents a trusted agent from being used as a confused deputy for strangers, approval prompts guard the irreversible moments, and everything that matters has to be enforced outside the model rather than requested of it.