AFA Protocol privacy notice

This notice is part of the AFA Protocol beta terms. You accept it at the same time. It says what we hold, why we hold it, how long, and what you can make us do about it.

Counsel has not reviewed this document. It was written and approved by the operator of the service. A review is pending, and this paragraph will be removed when it has happened, which will change the version and the hash.

Infrastructure Driven Growth And Future (IDGAF Holdings LLC) decides what is held here and why. Write to idgafholdingsllc@gmail.com.

The one thing to read if you read nothing else

We record hashes and metadata. We do not record what your agent said, what it was asked, or what a tool returned.

The client is built to send a hash of a tool's arguments rather than the arguments themselves, and the store holds a payload_hash and never a payload. That is not a policy we could quietly change without you noticing: a hash is what the chain is built from, and a record carrying content instead would look different to anyone reading their own export.

The exception is you. If you put content into a field that takes free text, we store the text you put there. That is true of an inquiry message, a waitlist entry, a continued-access request, the reason on a key application, a grant's purpose, the reason given for an override, a delegation order's task, the names in a grant's delegation path, the tool and target labels sent with a grant check or use, an execution id, a note on a policy proposal, and any field of an event you fill in yourself. Read what your client sends before you send it.

One check reads text and keeps only its hash. If your software uses the output check, it sends us the text your agent is about to ship. We scan that text in memory to answer allow, redact or block, and we keep its SHA-256 hash and the decision, never the text. Anyone who holds the text can match it to the hash, and so can anyone who guesses a short or predictable text.

What we hold

Your account. Your email address, the first and last name you gave when you signed up, when the account was created, when it last signed in, and whether it is an administrator.

Your keys. For each API key: an identifier, a prefix, the machine name and any label you gave it, when it was created, when it expires, when it was last used, whether it was revoked, and its capability scopes. We do not store the key itself, only a hash of it, which is why we cannot show you a key again after it is issued. For each key you apply for: the machine name and label, the scopes you asked for, the reason you gave, and the decision, with when it was made, which administrator made it, the scopes approved, and any note the administrator wrote.

Your records. For each event: the identifiers, sequence numbers, hashes, signatures, decision and timestamps you send. Not the payload. Also the public keys your machines register to sign records, and the signed checkpoints and chain positions built from your records.

Your grants. For each sub-agent grant: the grant id, the sub-agent and parent names you chose, the allowed tools, the call budget, the expiry, when it was recorded and a stamp the service derives from that time, and, when you set them, a purpose sentence, wallet caps (an asset, per-transfer and total limits, and a list of allowed recipients), a capability id from your own catalogue, and a delegation path (the ordered names the grant's authority came down through). For each later action on a grant, a row saying what happened and when: a use (how many calls), a transfer (the amount, the asset and the recipient), a revoke, or an override. An override also holds the tool it covers, until when, the reason given, and the email address of the signed-in person who decided it; that address is inside the signed record of the override. A use can also name the tool it was for and the target it acted on, and a grant, a use or a transfer can carry an execution id you send to link it to your own run. Each grant row written from 3 October 2026 also holds a record id, a digest of the inputs that decided it, a version of the service code that decided it, a version of the policy rules in force, its position in your grant record chain with the hashes that link it to the record before, and the service's signature over the row with the id of the signing key. Rows written before these fields were added lack some or all of them, and nothing already written is rewritten. Recipients, purposes, reasons, names, tools, targets and execution ids are stored exactly as typed, so the free-text rule above applies to them.

Your grant checks and refused uses. From 3 October 2026, every time your software asks whether a grant allows a call, and every time a use is refused, we keep a record of it, separate from your grants: the grant id, the sub-agent name, the tool and target if you sent them, your execution id if you sent one, the outcome, the reason, the count or transfer asked for in a refused use, the capability id of the grant, a digest of the inputs that decided it, a version of the service code that decided it, a version of the policy rules in force, the time, a record id, its position in its record chain with the linking hashes, and the service's signature with the id of the signing key. These records never count toward a budget or a wallet cap.

Your exported decision records. When your software exports your grant decisions in the TRACE format (GET /v1/trace/export), the first export of each use, grant check or refused use that carries an execution id stores a signed copy of it in that format, so that every later export returns the same bytes. A copy holds your account id, the sub-agent name, the execution id, the tool and target (or, for a transfer, its asset, never its amount or recipient), the outcome, a version of the policy rules in force, the time of the decision, its position in the export chain with the hash that links it to the copy before, and the service's signature with the id of the signing key. Beside each copy we keep a reference to the record it was made from: its id and position, the grant id, the outcome and reason, its input digest and the code version. For each kind of decision we also keep the export's position: how far it has reached, the hash of its last copy, counts of what was exported and what was skipped, and, if it stopped at a record it could not verify, which one.

Your delegation orders. For each signed order one machine gives another: the two machine names, the task and scope you wrote, how many uses it allows and how many were made, when it expires, the service's signature over it, and when it was revoked if it was.

Your output checks. For each check your software asks for: the SHA-256 hash of the text, the decision (allow, redact or block), which kinds of finding there were and how many of each (for example a private key, an access token, an email address or a payment card number), the scanner version, a digest of the inputs that decided it, a version of the service code that decided it, your execution id if you sent one, the time, a record id, and the service's signature with the id of the signing key. Never the text, never a matched value, and never the redacted text we return when you ask for one. The hashes of known values you send for a check are used for that check and not kept.

Your policy proposals. When your account proposes, approves, enacts or rejects a policy rule: the rule, the count of refused attempts offered as evidence, which key or signed-in session acted, any note given, and when.

Your agreements. For each document you accept: the document id, its version, the content hash of the exact text you were shown, the time, and the network address the acceptance came from. The address is there so an acceptance can be shown to somebody later; an acceptance nobody can place is not worth much.

Your usage. A count of calls per day, per key, per capability, and which kinds of client each key has been used from (for example the API, the hosted tools or a command-line client, as your software declares it), with when each was first seen. Counts, not contents. An administrator can see these counts per key.

Your notices. The notices we send you (a key expiring, a grant revoked, overridden or about to expire, an application decided, the free period ending, a deletion request recorded, your account being deleted) and, for each one, which way it went (in the console, by email, or to your webhook), whether it was sent or failed, the email service's message id, and the error if it failed. We keep this so we can tell whether you were actually told something, and send it again if not.

Your webhook. Webhook delivery is a channel you choose, and we deliver to it when the service has it switched on. If you register a webhook: its address, the network addresses it pointed to when you registered it, and a value we use to derive its signing secret (the secret itself is shown to you once and is not stored). For each notice sent to it: the message (the notice's type, severity and text), the signature headers, whether the receiver accepted it, how many attempts were made, and the receiver's last answer or error. For each delivery attempt: when it started and finished, the network address we connected to, the outcome, the receiver's status code, and the error if there was one.

Your anchor receipts. For each time your account asks us to anchor its records: the root of your records at that moment, the short record we hashed (your account id, that root and the time), and the public log's entry id, time and proof, or the error if the attempt failed.

Your deletion request. If you ask from a signed-in session for your account to be deleted: a request id, the address on the account at that time, and when you asked.

Your walkthrough progress. Which chapters of the in-console walkthrough you have finished and the one you were on, so you can carry on from another device. Nothing you type in it, and no timings.

Your messages. If you send an inquiry, join the waitlist, or ask for continued access: what you wrote, the details you gave (such as your name, organisation, address and expected use), and when. For a waitlist entry, also whether our confirmation email was sent.

Our logs. Ordinary service logs: request paths, status codes, timings, network addresses and the browser or client name your software sends. These are for running the service, finding faults and dealing with abuse.

Our access records. When an administrator opens your account's activity, reads its meter reconciliation, resends a notice to you, reminds you about a key, erases your grant records or deletes your account, we record who did it, when, and what was done (for example how many records were read or removed).

Why we hold it

• To run the service and to authenticate you.
• To produce the record, which is the product. A grant's history is part of the record: it shows who allowed what, within which limits, and who decided an exception.
• To check text before your software ships it, when your software asks, and to keep a record you can show that the check happened.
• To tell you things you need to know: a key expiring, a chain break, a grant revoked, the free period ending.
• To answer you when you write to us.
• To find and fix faults, and to deal with abuse.
• To show that an agreement was made, if we ever have to.

How long

• Your records, grants, grant checks, refused uses, delegation orders and output checks: while your account exists, and for thirty days after a closure we initiated so you can still export. A grant that is revoked or has expired stays in the history. A grant row, a refused use or an output check is never removed on the service's own initiative. Grant checks are kept the same way unless we switch on a check retention period, and it is not switched on today. If we switch it on, grant checks older than that period are removed, the removal is recorded in your chain as a signed mark saying how many records were removed and up to which point, and this notice will state the period.
• Your exported decision records and export positions: while your account exists. A copy of a grant check is removed after that check is removed under a retention period.
• Your account and keys: while your account exists.
• Webhook records, anchor receipts, policy proposals, notice and walkthrough records, and a continued-access request: while your account exists. Removing a webhook removes its address and settings; the messages sent to it and the record of each delivery attempt stay until your account is deleted.
• A deletion request: until the deletion is carried out. After that, its id and time are kept in our access record of the deletion.
• Agreement acceptances: kept after closure and after deletion. They are the evidence that an agreement was made, and deleting them would destroy the only thing that shows what you agreed to.
• Inquiries and waitlist entries: kept while we may still need to answer them, and for our own record of what was asked.
• Service logs: up to ninety days, then deleted.

Who else sees it

• Our hosting provider, which runs the containers and the database.
• Our email provider, which sends sign-in codes and notices. It sees your address and the text of the message.
• A webhook endpoint you register, which receives the notices we send it. We send only to an endpoint you chose and control, and only while the service has webhook delivery switched on; while it is off, no endpoint can be registered and nothing is sent.
• A public transparency log, if you ask us to anchor your records. We anchor to Rekor, the public Sigstore log. Anchoring happens only when your account asks for it (POST /v1/anchors/run); nothing is anchored on a schedule. The log receives a SHA-256 hash of the short record described above, a signature over it made with a key used only for anchoring, and that key's public half. It never receives the short record itself, your address, or the content of any record, and the key is the same for every account, so an entry shows that this service anchored something, not whose records they were. Entries in that log are public, anyone can read them, and they are permanent: we cannot remove one, and neither can you.

We do not sell your data. There is no advertising in this service, no tracking across sites, and no third-party analytics in the console.

What you can make us do

• Get a copy. Ask and we will send everything we hold for your account. You can also export most of it yourself through the API at any time, and your grant decisions in the TRACE format.
• Correct it. Tell us what is wrong and we will fix it. Note that a stored RECORD is corrected by adding a record that says what was corrected, not by editing the original; that is how the chain works, and it is in the terms. A grant is corrected the same way: revoke it and grant again.
• Delete it. Ask and we will delete your account and its records. Ask from a signed-in session with POST /v1/me/deletion-request (an API key cannot ask), or write to idgafholdingsllc@gmail.com. An administrator carries the deletion out. First, sign-in and every API key stop working. Then one last email is sent to tell you the deletion is happening. Then your account and its records are removed together, in one step: your keys and key applications, records, grants, grant checks, refused uses, delegation orders, output checks, exported decision records and export positions, usage counts, notices and their delivery records, webhook settings and deliveries, anchor receipts, policy proposals, walkthrough progress, any continued-access request, and the deletion request itself. What is kept is described below. You can also ask us to delete only your grant records, grant checks and refused uses, with their exported copies; that leaves the same signed markers described below and the export positions, so a later export continues from where it stopped.
• Object, or ask us to stop. Write and say so.

Write to idgafholdingsllc@gmail.com for any of these. We will answer within thirty days and tell you what we did.

What deletion cannot reach

Deletion removes your data from the service. It cannot reach a copy you or anybody else already exported, a backup until that backup rotates out on its ordinary schedule, or our email provider's own record of messages it sent. A signed record the service already handed to you (a grant record, a grant check, a refused use, an output check or an exported decision record) stays verifiable against our published key after deletion, wherever a copy of it is kept.

It cannot reach an anchor entry in the public transparency log either: that entry holds only a hash and our signature over it, but it is permanent and public.

Deleting your account does not remove an inquiry or a waitlist entry, because those were sent without an account and are kept under the address they came from. Write to idgafholdingsllc@gmail.com, say which address, and we will delete those too.

We keep the minimum needed to show an agreement was made, to show what was deleted, and to deal with abuse. That minimum is your address and your acceptance rows; one small signed marker for each of your record chains that had a record, saying that the chain was deleted, its last position and that position's hash, how many records were removed, and when, along with any retention mark already written; and our access records about your account. A marker holds your account id and no grant content. It exists so that the deletion itself cannot later be mistaken for tampering. The access record of the deletion says who carried it out, when, the id and time of your request if you made one, whether the last email was sent, and how many records of each kind were removed.

Where the data is

The service runs in the United States. If you are somewhere else, your data is handled there.

We have not completed a transfer assessment for any other jurisdiction, and we are saying that rather than implying it is done. If you need one before you can use this service, write to us and say what you need; the honest answer today is that it does not exist yet.

If something goes wrong

If we find that data has been exposed, we will tell affected account holders at the address on the account, say what we know, say what we do not yet know, and say what we are doing about it. We will do that whether or not we are required to.

Changes to this notice

This notice is versioned and its content hash is computed from its own text. A new version does not apply to you until you accept it, and you will be asked at your next sign-in.

Contact

Infrastructure Driven Growth And Future (IDGAF Holdings LLC)

idgafholdingsllc@gmail.com