# AFA Protocol

Canonical site: https://afaprotocol.com/
Operator: Infrastructure Driven Growth And Future (IDGAF Holdings LLC)
Organization site: https://www.idgaf.world/

AFA Protocol helps teams control what tool-using AI agents may do. On a supported host, it can check an action before the tool runs, pause higher-risk work for a person, and keep a signed record of what happened afterward.
The goal is more useful agent work without unlimited access: longer tasks with stop points, spending that can pause for approval, several agents with clear owners, and better records for review. These are practical operating examples. AFA does not claim a measured capacity multiplier, token reduction, or cost saving.

Primary product surfaces:
- MCP: connects AFA action checks and signed records to compatible agent hosts.
- Hosted API: Coming Soon. Team accounts, durable storage, usage counting, notification delivery, and matching verification results remain launch gates.
- SDKs and portable .authority bundles are special cases for particular integrations and evidence handoffs. They are not separate product surfaces.

How AFA helps agent work:
- Give a task a named owner, purpose digest, time mode, and parent.
- Narrow the tools, files, network access, and spending the task may reach on supported hosts.
- Compare signed envelopes as work branches, making changes to actor, purpose digest, scope, action class, time mode, and ordered plan visible.
- Allow a lower-risk action, ask a person about a higher-risk action, or deny an out-of-scope action.
- Keep signed summaries of the request and result without storing raw prompts, code, or secrets.
- Preserve who delegated work to whom and what happened first for later review.

Drift boundary:
- AFA surfaces structural drift; it does not infer intent from private reasoning.
- The envelope delta reports changes but does not enforce them by itself.
- Parent-scope containment and complete per-child path and call-budget enforcement remain open gates.
- A supported host must deliver the action to an active AFA pre-tool gate. Broad envelopes still permit broad behavior.

Cryptographic accountability:
- AFA does not inspect hidden reasoning or claim to detect a hallucinated thought.
- Standard signatures help show whether a recorded event changed after signing.
- Ordered hash links separately help show where the event belongs in the workflow. Approval before an action is different from approval added afterward.
- AFA uses standard cryptographic foundations and preserves recorded order.
- Order sensitivity is a protocol property, not a separate cryptographic hardness claim.
- Signed chronology and content digests may support an IP dispute, but they do not decide ownership, originality, authorship, infringement, or truth.
- Token budgets and paid inference are things AFA may govern. Hosted metering remains open, and AFA has not measured token-cost reduction.

Important boundaries:
- The website is static. Hosted accounts and REST access are Coming Soon.
- The authority record stores structural fields and one-way payload digests, not raw prompts or private reasoning.
- A valid signature and a correct place in the timeline are separate checks.
- A signed event is evidence that particular bytes were signed. It is not proof that the content is true.
- AFA works alongside operating-system permissions, IAM, and sandboxes. It does not replace them.

Public pages:
- / — product story and value for agent work
- /security.html — plain-language security checks and limits
- /privacy.html — public-site privacy statement
- /coming-soon.html — hosted launch gates