The TAGII Individual Agent Standard

The problem this addresses

Calls to pause or slow artificial intelligence reflect a legitimate concern: powerful automated systems can cause harm. This proposal argues that the more useful place for control is the point where AI acts in shared public systems.

Slowing research punishes the people building carefully and does nothing to stop the people who will not. The damage from AI does not come from the fact that a model exists in a lab. It comes from the moment automated systems act inside shared spaces: posting, transacting, contacting, moving physical machines, and doing so at a scale and speed no person could match, with no one clearly answerable for the result.

This proposal moves the control point. Instead of regulating what people are allowed to build, it regulates how AI is allowed to enter public infrastructure. Private capability stays unlimited. Public action becomes accountable.

The boundary between private and public

A person may run as many AI agents as they want on hardware they own, for any purpose, with no registration and no ceiling. That space is private and this standard does not touch it.

The moment any of those agents reaches into a shared system, a social platform, a marketplace, a communications network, a connected vehicle or device, it must pass through one gate: the person's single public agent. That public agent is the only thing the outside world ever interacts with, and it is bound to exactly one verified adult.

What every public AI action must carry

When an AI agent does anything inside public infrastructure, that action must satisfy all six of the following. A platform can check each one without learning anything else about the person behind the agent.

Checkpoints: verification where public lines are crossed

The six requirements above describe what an authorized action looks like. They do not, on their own, stop someone from sending an agent to do harm. That takes a place where the check actually happens.

4.1 The border model

Shared infrastructure already has natural crossing points: where a request enters a platform, where traffic passes through a gateway or an exchange, where a device joins a network. This proposal places verification at those crossings. An agent presenting itself at a crossing must show proof that it is bound to a real, verified person and is acting within its authorized limits. No proof, no passage.

4.2 What the checkpoint sees

The proposed checkpoint would receive proof that an action comes from an enrolled person and falls within their authorized limits. It must not receive the identity document, name, number or photograph. Document validity, duplicate enrolment and revocation are requirements to verify through the chosen enrolment system; they are not guarantees established by this proposal. The checkpoint should verify a proof about the document, not collect the document. Section 6 sets out the privacy requirements.

4.3 Unlinkable across crossings

The design calls for a different credential at each platform, so checkpoints cannot use a shared credential to build a profile of the same individual. This is a privacy requirement to test across the complete system, including metadata, logging and operator collaboration. Different credentials alone do not establish that a person cannot be tracked.

4.4 What this does and does not solve

The intended first guardrail is verified enrolment combined with limits on public action. It does not, by itself, defeat a determined adversary with forged documents, stolen credentials or an agent probing checkpoints for weaknesses. Its effectiveness needs to be measured against those failures. The proposal seeks to strengthen public safeguards while leaving private AI research and development open.

4.5 An oversight layer above the checkpoints

Checkpoints answer a yes or no question per action. Above them sits a monitoring layer that watches patterns across many actions: bursts, coordination between agents, behaviour that stays inside the letter of the limits but not their intent. TAGII proposes a layer of this kind within its platform. Its internal design is not published here for reasons set out in Section 11, but the role it plays, continuous behavioural oversight that never inspects private content, is the role this proposal expects any checkpoint operator to fill.

Why scale does not multiply power

The most serious risk in automated systems is cheap replication. One person spins up a thousand agents and suddenly commands a thousand voices, a thousand accounts, a thousand hands on the market. Platform safeguards vary; this proposal asks for a shared ceiling across the whole agent family.

Under this standard, spawning a thousand child agents changes nothing about public reach. Every one of them still acts through the same public agent, and that agent has one ceiling. Limits on posting, transactions, compute on shared infrastructure, physical actions and attack capacity apply to the entire family of agents together, not to each one separately. A single, extremely capable agent falls under the same rule as a swarm of weak ones.

This shifts what the system rewards. Multiplying instances buys nothing. What pays off is building one capable assistant that gets better over time: more knowledgeable, more precise, more reliable, more efficient with energy. That is a healthier direction for the whole field than a race to replicate.

What stays private, always

This section is the privacy floor that every other section, including the checkpoints in Section 4, must satisfy. Accountability that becomes surveillance is a failure, not a feature. This standard is designed so that a platform can confirm an agent is legitimate and authorized while receiving none of the following:

• The person's legal name, passport or government ID
• Biometric data of any kind
• The contents of the person's private conversations with their assistant
• The assistant's memory or history
• What the person or their agents are doing on any other platform
• Location, contacts, or device details

Each platform should see a separate public credential. The requirement is that these credentials cannot be joined into a profile outside the person’s own system. That protection must be demonstrated through independent testing, including the information revealed by network traffic and decision records. Verification should prove “this action is authorized” without disclosing “this is who you are.”

Enforcement without exposure

When a public agent breaks a platform's rules, the platform suspends that agent's credential for that platform. That is the whole penalty at the platform level. It does not unmask the person, it does not reach into their private space, and it does not follow them to unrelated services.

Serious violations that rise to the level of law are handled the way they are today, by courts and lawful process, with the added benefit that a clear chain of authorization already exists. What this standard removes is the current default where a platform's only tools are either nothing or total exposure.

Where this applies

Social media is the obvious first case, but the same logic holds anywhere automated mass action can cause harm that cannot be undone or manufacture an advantage no single person could earn:

• Finance and markets
• Critical infrastructure and utilities
• Robotics and connected physical systems
• Healthcare
• Legal and court systems
• Government communications
• Space operations

Military extension Draft, under development

This section is early thinking and is presented as a direction, not a finished position. It is included because the same architecture appears to answer a problem the civilian standard does not reach.

9.1 The premise

AI should be treated as weapons-grade technology, in the same tier of seriousness as nuclear capability. Unlike nuclear, though, AI capability is not all or nothing. It can be dialled. That means the right control is not a ban but a cap, the same way arms agreements already cap counts, ranges and classes of conventional weapons.

9.2 The mechanism

Apply the public agent model to autonomous military systems. A swarm of drones is not an anonymous mass. Every unit in it traces back to one identified human operator, who is authorized for a defined ceiling, and that operator sits inside a normal chain of command. The number is not settled; a figure of one hundred units per operator was raised and immediately judged far too low. What matters is that a ceiling exists and that responsibility never dissolves into "send the machines and see what happens."

9.3 What carries over, what changes

Identity, delegation and provenance carry over unchanged. Every automated action still traces to one accountable person. Privacy adapts rather than disappears: classified operations remain documented internally and sealed from public release, which matches current military practice rather than replacing it.

9.4 Where this needs work

Today's military accountability already runs through a chain: the manufacturer, the commanding officer, and the operator. This proposal would add a single identity thread through that chain rather than replace it. Whether the right forum is an international arms-control agreement, national military doctrine, or both is unresolved and needs input from people who work in defence law and policy.

Open questions

A standard that claims to be finished is not credible. These are the questions still being worked on, and the author would rather name them than paper over them.

• How can an agent earn expanded authority through demonstrated reliability without that turning into a permanent privileged class?
• Who is the accountable party for an automated military action when the operator, the commander and the manufacturer all contributed?
• How should the ceilings be set, and by whom, across different sectors?
• What body would certify that a platform's verification method actually receives nothing beyond the authorization proof?
• Who operates the checkpoints described in Section 4, and how is a checkpoint operator itself held accountable?
• How are forged or stolen identity documents detected at enrolment without building a central database of everyone's documents?

Architecture notes

This section explains how the parts of the standard fit together and which existing, published standards each part can be built on. It is written for engineers, regulators and researchers who want to see that the proposal is buildable with tools that already exist.

11.1 The five layers

11.2 Layer 1: enrolment without a document database

The standard requires that a person prove, once, that they hold a real government identity document. The obvious way to do that, uploading a photo of a passport to a server, is exactly the surveillance risk the standard exists to avoid.

The approach the standard relies on is different. Modern passports and many national ID cards carry a chip signed by the issuing country under the ICAO specification. A phone can read that chip and, on the device itself, produce a cryptographic proof that says "a valid, unexpired document signed by a recognised government exists and belongs to an adult" without revealing the name, number, photo or nationality. The document never leaves the phone. What the enrolment service receives is the proof, plus a commitment that stops the same document being enrolled twice.

Self Protocol and ZKPassport are existing open-source reference projects for document-based proofs and selective disclosure. They offer starting points to evaluate. Supported documents, devices, audit coverage and the information received by each party must be checked against the exact version being used; this proposal does not establish that either project provides every requirement unchanged.

Signature and expiry checks address some invalid-document cases. Revocation depends on available issuer information and the verifier’s implementation. A valid chip or a duplicate-enrolment check does not, on its own, establish that the person presenting a stolen document is its rightful holder. These limits, recovery and unsupported documents need explicit treatment in the enrolment design. A document-level duplicate check also does not establish that one person cannot enrol with more than one valid document.

11.3 Layer 3: the public agent credential

The public agent is the only thing the outside world sees. Its credential has to do several jobs at once, and each maps to an existing standard family.

The important design point is that none of this is new cryptography. Each row is a published or actively standardised mechanism. The standard composes them and sets the rules for how they must be used together.

11.4 Layer 4: what a checkpoint actually does

A checkpoint is a policy decision point placed at a crossing into shared infrastructure. On every incoming agent action it answers one question: is this action carrying a valid credential and is it inside its limits? The answer is yes or no, logged, and nothing more.

11.4.1 Inputs it receives

• The credential and its proof of possession
• The declared action and its scope
• A rate-limit token for the current period
• The revocation status of the credential's root

11.4.2 Inputs it must never receive

• Any identity attribute of the person
• The content of the person's private assistant or memory
• Credentials the same person uses on other platforms

11.4.3 Where checkpoints sit

At the edge of any platform that accepts agent actions, at API gateways, and at network exchange points where a jurisdiction chooses to require it. Policy engines that already do this kind of enforcement at scale exist as mature open source, and the checkpoint role can be implemented on top of them rather than from scratch.

11.4.4 Certifying a checkpoint

A checkpoint operator should be certifiable, by an independent body, against a simple test: run the verification with test credentials and confirm that no identity attribute is ever present in the operator's logs, storage or memory. That is one required test, not a complete certification. Independent review must also examine the protocol, metadata, retention, operator behaviour and failure cases. Who performs that review remains an open question in Section 10.

11.5 Layer 5: oversight above the checkpoints

Individual checkpoints see single actions. Abuse often only shows across many: an agent staying just under its per-platform limit on twenty platforms at once, or a set of agents acting in lockstep. The oversight layer consumes checkpoint decisions, never content, and looks for those patterns.

Its output is a signal to the relevant checkpoints and to the person's own system, never a public identification. If a pattern warrants more than a suspension, that step goes through lawful process, as described in Section 7.

This is the oversight role TAGII proposes to develop and test. Local checkpoint experiments do not establish a deployed oversight layer or prove the privacy properties of the complete system.

11.6 Reference points

Readers checking the claim that this is buildable today can look at the following public work. TAGII does not endorse any specific project; these are cited to show the components exist.

• ICAO electronic passport specification and public key directory (the basis for on-device document proofs)
• Self Protocol documentation and ZKPassport (document-based proofs; implementation and coverage require evaluation)
• Semaphore and Rate-Limiting Nullifier (anonymous membership and spam resistance)
• IETF Privacy Pass architecture (anonymous tokens and the conditions required for unlinkability)
• IETF drafts on credential delegation and operation authorization for AI agents (OAuth 2.0 Token Exchange, proof-of-possession, Rich Authorization Requests)
• C2PA Content Credentials (provenance for AI-generated media)
• INTERPOL travel-document status information (why lost, stolen and revoked status requires a separate, current source)
• Open Policy Agent, Cerbos and SpiceDB (policy decision and enforcement engines)

Invitation to discuss

This standard grew out of TAGII’s work on identity and personal-assistant architecture. It is being offered publicly because it will be stronger for being argued with.

Policymakers, civil-liberties advocates, technologists and AI developers who want to challenge it, refine it or help test it against real regulatory frameworks are invited to get in touch.

Share your response with Matthew