A modular authority stack
Permission Zero is designed as a layered authority and defense architecture rather than one monolithic identity product. The autonomous internet has several different trust problems: proving that a legitimate principal exists, identifying the software actor, expressing delegated authority, enforcing that authority at action time, and detecting harmful coordination across populations. Trying to solve all of them with one credential creates complexity and weakens the boundaries between concepts.
The five-layer model keeps those responsibilities separate while allowing them to work together. Applications can adopt only the layers they need. A low-risk community system may begin with Human Proof. An enterprise agent platform may focus on Agent Identity and Delegated Authority. A marketplace may combine all five because it has both authorized agents and swarm-abuse risk.
Layer 1 - Human Proof
The Human Proof layer establishes a legitimate human root when the policy requires one. The key design objective is minimum disclosure. A service may need evidence that a proof provider has established the required personhood or uniqueness property at an accepted assurance level, that a person satisfies an eligibility condition, or that a human root authorized an agent. It should not automatically receive a complete identity dossier to answer those questions.
The layer is provider-agnostic. Different environments can use different proof mechanisms, from privacy-preserving uniqueness systems to enterprise identity providers or regulated verification. Permission Zero is designed to consume the proof result and its assurance level as an input into authority decisions rather than requiring one universal identity database.
Layer 2 - Agent Identity
The Agent Identity layer gives each autonomous actor a stable identifier bound to rotatable cryptographic keys or credentials. This provides continuity across actions, supports reputation, enables targeted key or credential revocation, and creates an object to which permissions can be attached. The agent identity is intentionally separate from the human identity. Software should be able to disclose that it is software rather than impersonating the person behind it.
Identity metadata can include the agent's issuer, software class, public keys, attestation information and lifecycle state. The exact schema can evolve, but the fundamental purpose is to make autonomous actors addressable and accountable.
Layer 3 - Delegated Authority
Delegated Authority converts intent into a bounded capability. The delegation can specify actions, resources, spend limits, time windows, counterparties, concurrency, geography, escalation conditions and revocation. A human-authorized agent can therefore prove not only who it is but what it has been empowered to do.
Delegations should support chaining without privilege expansion. If one agent calls another, the derived capability should remain within the original envelope unless a fresh authority grant is obtained. This preserves provenance through complex multi-agent workflows.
Layer 4 - Policy Enforcement
Policy Enforcement evaluates a requested action against the active delegation and current context. This layer is where static permission becomes a live decision. The engine can inspect resource sensitivity, accumulated spend, time, destination, reputation, risk signals and any application-specific rule that matters to the action.
The result is richer than a boolean. Permission Zero envisions outcomes such as allow, allow with limits, challenge, require human approval, isolate or deny. Each decision should carry an auditable reason code so operators and users can understand what happened without reverse-engineering an opaque model.
Layer 5 - Swarm Defense
Individual authorization cannot detect every form of abuse. A population of actors can each remain within local limits while collectively scraping a service, capturing scarce inventory, creating synthetic accounts or exhausting an API. Swarm Defense therefore evaluates behavior across identities and time.
Signals may include synchronized timing, shared targets, common infrastructure, repeated action sequences, authority concentration and correlated retries. The output can feed the same enforcement layer, allowing the application to apply adaptive friction or population-level limits even when no single request is obviously malicious.
Receipts and auditability across the stack
Authority decisions become difficult to govern if they disappear after execution. Each consequential action should be able to produce a compact receipt: which actor requested it, which authority path applied, which policy version was evaluated, what decision was made, and which reason codes contributed. The exact storage model can differ by deployment, but the principle is that important decisions should be reconstructable.
Receipts help developers debug policy, allow organizations to review agent behavior, and provide evidence in disputes. They also create a basis for later governance without requiring every internal detail of the system to be public.
Separation creates crypto-agility and policy agility
The protocol should be able to evolve its cryptography and policy mechanisms without forcing every component to change at once. Proof systems, signatures, key formats and attestation methods will change over time. A modular architecture allows a new proof mechanism to be accepted by the Human Layer while the delegation model remains stable. Similarly, Swarm Defense models can improve without changing the identity format.
This separation also supports different trust environments. A regulated financial deployment can use stronger identity and approval requirements than a public developer tool while preserving the same conceptual authority flow.
Deployment model: edge decision, local policy, portable proof
A practical deployment can keep application-specific policy close to the application while allowing proofs and delegation formats to remain portable. The relying service sends a structured action request to a local or hosted policy component. That component verifies the relevant proof chain, checks the active delegation and combines it with local resource policy. Sensitive business rules do not have to be published globally in order for the authority evidence to be interoperable.
This hybrid model also reduces latency and concentration risk. High-frequency decisions can be evaluated near the application, while common verification libraries and schemas keep the ecosystem compatible. Over time, different implementations can compete on performance and assurance without forcing every relying service into one centralized decision provider.
What Permission Zero is building toward
The architecture is a roadmap, not a claim that every layer is already production-complete. The current Permission Zero site presents the conceptual model, research direction and controlled simulations. The engineering path is to turn the model into interoperable specifications, SDKs, policy primitives, test environments and eventually audited production components.
The destination is an authority layer that applications can call as naturally as they call identity or payment infrastructure today. Humans and organizations remain the roots of legitimate power. Agents become explicit actors with bounded capabilities. Policies are enforced at action time. Swarms are evaluated at population scale. That combination is how Permission Zero intends to make autonomous systems useful without making authority invisible.