Attestation vs. authorisation

Agent identity has to answer two questions. The industry just started on one of them.

In June, CrowdStrike announced Continuous Identity for AI Agents: verifiable identities based on the SPIFFE standard in place of static API keys, and real-time authorisation that grants, denies and revokes an agent's access based on risk. At Fal.Con in September it added an Agentic Identity Provider, to establish what an agent is before deciding what it may do. CrowdStrike notes that the unreleased parts are still in development.

That's good news for anyone running agents. A major vendor has said plainly that service accounts and API keys are not an identity model for software that acts on its own. It also leaves the second question open.

Two questions

"May this agent do this?" is not the same as "What did it just do?"

Authorisation is a decision made before an action. Attestation is evidence produced after it, that someone other than the enforcing platform can check.

Authorisation (CrowdStrike Continuous Identity)Attestation (Agentic Trust & Protection Platform)
Question answeredMay this agent perform this action, right now?What did this agent actually do, and is it still the agent that was approved?
OutputA grant, a denial or a revocationA signed, time-limited trust-state record, plus a public badge and verify page
WhenBefore the actionAfter it, checkable later
Who can check itThe platform enforcing the policyAnyone: the installer, an auditor, a customer. No account needed.
Third-party MCP serversNot addressed in the announcementsEvery server in the official MCP registry, scored daily
StatusAnnounced; unreleased parts in developmentLive: scoring, badges and verify pages
They fit together

Authorisation needs good inputs. Attestation is one.

A policy engine deciding whether an agent may act is only as good as what it knows about that agent. A signed record that the agent, or the MCP server it is about to call, changed after it was approved is exactly the kind of signal it should weigh. We built Agentic Trust & Protection Platform on SPIFFE so that record can feed any enforcement layer, CrowdStrike's included, without locking anyone into ours.

To be clear about the boundary: Agentic Trust & Protection Platform does not enforce access and is not an identity provider. It produces evidence that others can verify and act on.

The gap: third-party MCP servers

Agents call tools their owners didn’t write

An agent's permissions are only half its risk. The other half is the MCP servers it installs, which are published by third parties and change without notice. As of 20 September 2026, our scan of 33,751 servers in the official MCP registry found that 95% of servers that ship a package publish no content hash for it, and 25% authenticate with a long-lived static secret. An identity for the calling agent does not change either fact.

Limits

What we don't claim

A registry score is a static claim about a published manifest at a point in time. It does not say a server's code is safe or that it behaves at runtime the way it did under scan. An attestation says what was observed and signed; it is not a promise about the future. The badge charter sets out the rules we hold ourselves to.

Sources: CrowdStrike, "CrowdStrike Unveils Continuous Identity for AI Agents" (15 June 2026) and the accompanying blog post; SiliconANGLE, "Agentic Identity Provider arrives at CrowdStrike Fal.Con" (3 September 2026). Registry figures: trust.redthreadsec.com/mcp-scan.