← Blog
Agent Trust Fabric

Agent Trust Fabric: an identity, a record, and — soon — a checkpoint for every AI agent

What ATF gives an agent today, what the ATF Enforce preview adds, and — just as important — what we do not yet claim.

The MILLENNIUMS.AI team · 26 September 2026 · 7 min read

Ask a team that runs AI agents in production four questions. What did it actually do? What is it still allowed to do? How do you prove that to a customer? How fast can you stop it? Most of the honest answers today are a shrug. The agent authenticates with a long-lived key, its scope was decided once in a config file, and its history is whatever logging the author happened to write.

Agent Trust Fabric (ATF) is our answer to those four questions. It has three layers, and it is worth being precise about which of them exist today and which are still a preview.

Layer 1 — an identity that is not a shared key

Every registered agent gets its own SPIFFE-style identity and a short-lived signed credential, instead of an API key sitting in an environment variable. The identity is unique per agent, so “which agent did that?” has an answer, and it rotates, so a leaked credential ages out.

Layer 2 — a signed record of what it did

As an agent works, its actions are reported and turned into signed trust-state events in an append-only ledger. A badge — green while the agent stays inside its granted scope, red when it does not — is generated from that ledger, and a verification document lets someone else check the signature offline. The point of the signature is that the record is not merely the agent owner's assertion.

Be clear about what this layer is: it is a record. It tells you, quickly and verifiably, that an agent stepped outside its scope. It does not, by itself, stop the request that stepped outside — that request has already left by the time it is reported.

Layer 3 — ATF Enforce, a checkpoint (preview)

ATF Enforce moves the decision in front of the request. An inline gateway evaluates each outbound request against the agent's grant and answers allow, deny, or pause. The grant is structured — host, methods, paths, and a body-size cap — not just a list of tool names, because an attack sent through an allowed tool looks in-scope if all you check is the tool. A few properties we consider non-negotiable:

  • Fail closed. No policy means deny.
  • Read-only by default. A rule that does not name write methods allows none, and request bodies are capped.
  • A deny-list no rule can override — cloud metadata endpoints and private address ranges stay unreachable.
  • Shadow first. The same decision is computed in shadow mode and only recorded, so you can see what would have been blocked before anything is.

The burn-in gate

The failure mode of every blocking control is the false positive that takes production down, so we made the safe order a rule in code. An identity cannot move from shadow to enforce until the gateway has watched it do real work for a minimum period and enough decisions, and every request the gateway would have blocked has been reviewed and agreed by an operator. Reviews are grouped by host and method so an operator rules on a dozen patterns rather than hundreds of rows.

Receipts a third party can check

Enforced traffic carries a signed receipt header. A site that receives a request from an agent can hand us that header and get one of three answers: covered and allowed, covered and denied, or not covered at all. That last answer only means something once the site has already decided which traffic it suspects is an agent — scoping is the caller's job — but it is the one piece of ATF that helps a party who never adopted anything.

Third-party MCP servers

Agents also install code they did not write. Third-party MCP servers are added to an agent's configuration with little vetting, and no one owns the risk: the registry disclaims it, the author has no relationship with the installer, and the agent framework treats it as configuration. ATF scores public MCP servers and lets a publisher embed a verifiable badge, so an installer can check a server before adding it.

What we do not claim

ATF Enforce is a preview. Its decision engine, grants, signed policy bundles, receipts and burn-in gate are built and tested, and a gateway prototype has run in front of a real agent scan. We have not yet run it in enforce mode against a customer workload, and we have not chosen the production data plane. We therefore do not say it stops attacks in general. What we say is narrower: once an identity has passed its burn-in review, out-of-scope requests can be stopped before they leave.

That candour is deliberate. A security control that over-claims is worse than none, because people stop looking. It is the same rule we apply to our penetration-test findings: label how we know a thing.

Try it

Registering agents and reading their badges is free for your first ten. Start at trust.millenniums.ai, or read the identity documentation and the API reference. If you run agents that install third-party MCP servers and want to be a design partner for Enforce, tell us.

Keep reading

More from the blog.

Agent security
The agent that was blocked, so it found another way: what the Services Australia incident teaches
An AI research agent hit an access block on an Australian government service and kept going until something worked. What actually failed, and how we designed around it.
Platform
Agentless and graph-first: why we start with a map, and where the time and money go
Installing agents everywhere and triaging flat lists of findings are the two biggest hidden costs in security tooling. Here is how an agentless graph removes them.
Pentesting
What an AI penetration test costs — and what it does not replace
A manual pentest is a large, infrequent purchase. Autonomous agents make it small and frequent. The honest comparison, including the parts humans still do better.