The binary model is collapsing
For years, online systems have divided activity into two rough categories: human and bot. The distinction was useful when most automation was either background infrastructure or clearly unwanted scripted activity. Autonomous agents make the binary model misleading. A software actor may be operating legitimately for a human, independently for an organization, as a service in its own right, or as part of an abusive swarm.
Treating all machine activity as equivalent creates two problems. It blocks useful automation that users intentionally delegated, and it fails to explain the authority behind automation that is allowed. Permission Zero uses a four-actor model as a more practical starting point for policy.
Actor 1: Human
The first actor is the human principal: the person whose intent, rights or resources are involved. A human may interact directly with an application or may authorize software to act on their behalf. The important property is not that every action must be manually initiated; it is that legitimate authority can ultimately be traced to a real person when the policy requires it.
The Human Layer can establish that root with minimum disclosure. In low-risk contexts a service may only need confidence that a human satisfies an accepted personhood or uniqueness policy at a defined assurance level. In higher-risk contexts the service may require stronger identity or eligibility proof. Human is therefore an authority class, not one universal identity format.
Actor 2: Human-authorized agent
A human-authorized agent is software that has explicit delegated authority from a human. This category is central because it separates useful AI from anonymous automation. The agent should have its own identity and a machine-readable permission envelope describing what it can do, for how long, and under which constraints.
The agent is not the human, and it should not impersonate the human. A relying service should be able to see that an automated actor is present while also verifying that the automation is legitimate. This preserves transparency without forcing the person to stay manually in the loop.
Actor 3: Autonomous or service agent
Some agents may operate without a direct human delegation for each task. A company can run a service agent that manages infrastructure, provides customer support or monitors systems under organizational policy. A decentralized protocol may have software actors that execute predefined rules. These agents still need identifiable authority, but the root may be an organization, contract or governance process rather than one individual.
The distinction matters because policy should reflect the authority source. A consumer service may accept only human-authorized agents for sensitive actions, while a developer platform may allow organizational agents under enterprise controls. Permission Zero treats both as legitimate classes when their authority can be established and bounded.
Actor 4: Organization
Organizations are principals in their own right. They own resources, employ people, operate services and delegate authority to software. Organizational authority can be more complex than personal authority because it may depend on roles, approvals, budgets, environments and separation of duties. An agent authorized by a finance team may have different powers from one authorized by an engineering team even if both belong to the same company.
Representing organizations explicitly prevents the system from pretending that every machine action must map to one natural person. It also allows enterprise governance to participate directly in the permission model.
Where does hostile automation fit?
Hostile automation is not necessarily a fifth identity class. It is better understood as a behavioral state or relationship to policy. A human-authorized agent can become abusive if its credentials are stolen or if the human uses it to violate a service's rules. An anonymous agent can be benign. A swarm can consist of compromised humans, service agents and unknown clients at the same time.
This is why Permission Zero separates actor classification from Swarm Defense. Identity and authority describe what an actor is and what it is allowed to do. Behavioral analysis evaluates what the actor or population is actually doing. The two layers inform each other without being collapsed into one label.
Actor labels should be verifiable
The model is only useful if relying services can verify the relevant claim. A client should not be able to mark itself 'human-authorized agent' and receive privileged treatment. The service needs a proof path: a valid agent identity, an active delegation, a legitimate authority root and any contextual conditions required by policy.
Verification can be local or federated. A service may trust only delegations issued within its own environment, or it may accept recognized external issuers. The architecture does not require one global registry, but it does require that claims can be checked rather than simply asserted.
Policies become clearer when actors are explicit
Once the actor model is richer, product policies can become more precise. A marketplace might allow humans and human-authorized shopping agents to purchase normally, rate-limit unknown autonomous agents, and block coordinated swarms. A social platform might label agent-generated posts while permitting them, but require a human root for governance votes. A financial service might allow an enterprise agent to prepare payments while reserving final approval for a human officer.
The policy no longer needs to say 'bots are banned' when what the product actually cares about is authority, transparency, fairness or resource consumption.
From actor classes to interoperable policy
The value of an actor model increases when services can express policies in a common vocabulary. An application should be able to say that a certain endpoint accepts direct humans and human-authorized agents, that organizational agents require a trusted issuer, or that an anonymous autonomous actor receives a lower default rate. Those rules can be local while the underlying actor claims remain portable.
Interoperability does not require every platform to make the same decision. It requires them to understand the same kind of evidence. One service may welcome shopping agents while another prohibits them. Both can still benefit from knowing that the actor is an agent, which authority root it represents, and whether the delegation is active.
A vocabulary for a mixed internet
The autonomous internet will contain more than four implementation patterns, but the four-actor model gives product teams a useful vocabulary. Human, human-authorized agent, autonomous/service agent and organization describe different authority relationships. Swarm analysis then adds a behavioral dimension across those actors.
Permission Zero uses this vocabulary to make machine participation legible. The objective is not to create rigid social categories. It is to give services enough structure to express rules that reflect how people and software actually interact. When the actor and the authority path are visible, applications can support automation without surrendering control.