Access credentials do not capture the whole intention
API keys and session credentials often prove possession of access. OAuth is specifically an authorization framework and can restrict access through scopes; extensions such as Rich Authorization Requests can express richer authorization details. The gap Permission Zero focuses on is not that OAuth lacks authorization. It is that autonomous workflows may also need task-specific intent, quantitative limits, delegation provenance, revocation, action-time context and population-level behavior to be evaluated together. A long-lived or broadly scoped credential can still outlive the narrow human purpose that originally caused it to be granted.
This was manageable when software mostly executed deterministic application logic written by the service itself. Autonomous agents are different. They plan, choose tools, retry, negotiate and react to changing environments. The boundary between 'the user asked for this' and 'the agent decided this was useful' becomes important. The authority model must therefore travel with the agent's actions instead of being assumed from possession of a broad credential.
Delegation is a contract of capability
Delegated authority means converting human intent into an explicit capability envelope. The delegation can describe what the agent may do, which resources it may touch, the maximum value it may spend, the counterparties it may interact with, how long the authority lasts, and which actions require escalation. The agent is free to reason inside that envelope but cannot silently enlarge it.
A useful delegation should be machine-readable and auditable. 'Book my trip' is a natural-language objective; the permission layer might translate it into capabilities such as search flights, reserve refundable fares, spend up to a defined amount, use one payment method, and require approval before purchasing a non-refundable ticket. The exact policy may differ across products, but the principle remains the same: autonomy is bounded by explicit authority.
Least authority for agents
Security engineering has long used the principle of least privilege: give a component only the access it needs. Autonomous agents require a stronger version: least authority. The agent should not only have limited system permissions; it should have limited purpose, duration and context. A tool permission that is safe during one workflow may be dangerous after the workflow ends or when used with a different counterparty.
Short-lived, task-scoped delegation limits the blast radius of mistakes and compromise. If a travel agent is hijacked, the attacker should not inherit perpetual access to email, payments and calendars. If a coding agent is misled by untrusted content, it should not automatically gain production deployment rights. The permission envelope should make privilege escalation visible and require a new authorization decision.
Delegation has to survive composition
Real agents will call other agents and services. A planning agent may invoke a search agent, a payment agent and a delivery service. Authority should not become broader as it passes through that chain. If the original human approved a maximum spend of one amount, a sub-agent should not receive an unlimited payment credential. If the original delegation prohibited exporting personal data, an intermediate service should not be able to waive that restriction.
This suggests that delegation needs provenance. Each derived capability should be traceable back to the authority that granted it, with constraints that can only stay the same or become narrower unless a fresh approval is obtained. The system should be able to answer not just 'which agent acted?' but 'under whose authority, through which delegation path, and with which constraints?'
Action-time enforcement is essential
A permission document is useful only if it is checked when the action happens. Agents operate in changing environments, so a policy that was acceptable at the start of a task may no longer be acceptable later. A price can rise, a counterparty can change, a credential can be revoked, a risk score can worsen or a time window can expire. Permission Zero therefore treats enforcement as a live decision rather than a one-time registration event.
At action time, the policy engine can evaluate the agent identity, active delegation, requested capability and relevant context. The result can be allow, deny, rate-limit, challenge or require human approval. This makes autonomy resilient to changes rather than assuming that an authorization decision made hours or days earlier remains correct forever.
Humans need intelligible control
A technically precise permission system can still fail if people cannot understand it. Users should not have to read dozens of low-level API scopes to know what an agent can do. Permission needs a human-facing layer that summarizes consequential authority in plain language: what can be spent, what data can be accessed, which accounts can be contacted, how long the delegation lasts, and what events will ask for approval.
The system should also show meaningful changes. If an agent requests a broader scope than it previously had, that should be obvious. If a delegation is about to expire, the user should be able to extend it intentionally rather than having permissions renewed silently. Human comprehension is part of the security model because consent that cannot be understood is not reliable authority.
Organizations are authorities too
The same model applies to organizations. A company may authorize an AI procurement agent, coding agent or support agent, but the authority may come from a role, policy or approval chain rather than one individual. Enterprise delegations can incorporate budgets, data classifications, environments, separation-of-duties rules and escalation paths. The root of authority is organizational governance, while the agent remains a bounded executor.
This creates a common architecture across consumer and enterprise use. The root may be a person or an organization, but the agent still receives explicit capabilities, the policy is still checked at action time, and every consequential action can still be connected to an authority path.
Delegation makes legitimate automation easier to accept
Many services respond to automation by blocking it because they cannot tell whether it represents a customer, an attacker or an unauthorized scraper. Explicit delegation creates a third option. A service can accept recognized agents that present valid authority while applying stronger friction to anonymous automation. This is a more scalable future than trying to keep all software out of systems that users increasingly expect software to operate on their behalf.
The distinction also improves accountability. If an authorized agent behaves badly, the service can identify the delegation and apply a targeted response rather than banning an entire class of automation. Reputation can attach to the agent, the authority source or the service provider without conflating all of them.
Permission is the missing layer
AI agents do not only need identities. They need an answer to a more consequential question: what power has legitimately been delegated to this actor for this action? Broad credentials and permanent access are a poor substitute because they collapse identity, capability and intent into one secret.
Permission Zero is built around the opposite model. Human or organizational authority is explicit. Agent capabilities are bounded. Delegations can expire and be revoked. High-risk actions can escalate. Services can verify authority at the moment of use. The result is not less autonomy; it is autonomy that can be trusted because the limits are visible, enforceable and connected to a legitimate source of intent.