Agent Identity Scorecard
Is your AI agent stack actually production-grade?
10 technical questions. 3 minutes. A personalized report on whether your AI agent stack is production-grade for 2026 — graded against industry best practice, not regulators.
Looking for the regulatory version? See the EU AI Act Scorecard. This one is graded against engineering best practice — no regulator references.
1 of 10 · identity
Does every AI agent in your system have its own unique cryptographic keypair (Ed25519, RSA, or equivalent)?
Per-agent keypairs are the foundation. Shared API keys or service accounts mean "the agents" are one identity, not many — which collapses every downstream guarantee.
2 of 10 · identity
Are agent private keys generated server-side and shown to clients exactly once — never persisted in plaintext, never embedded in source, never stored in environment variables?
How keys are issued and stored matters more than which algorithm you use. A leaked .env file with private keys defeats the whole identity layer.
3 of 10 · permissions
Are your agent permissions scoped to the smallest set of capabilities each agent actually needs (least-privilege), rather than broad "agent can do anything" tokens?
Least privilege is the difference between a bad day and a bad year when an agent is compromised. "Scope: *" or "Role: Admin" defeats the model.
4 of 10 · permissions
Do agent permissions expire on a timer (TTL) by default — typically 2-24 hours — rather than being long-lived until manually revoked?
Long-lived credentials are the #1 blast-radius multiplier in agent incidents. Short TTLs limit how much damage a compromised credential can do before it auto-expires.
5 of 10 · permissions
When you revoke an agent's credentials, can every downstream system stop trusting that agent within a few minutes — not hours, not "next cache refresh"?
Revocation is only useful if it propagates. A compromised agent that stays trusted for 24 hours after revocation is effectively un-revoked.
6 of 10 · audit
Are your agent action logs hash-linked or signed in a way that makes after-the-fact tampering detectable, rather than relying on "trust the database"?
Hash-linked or cryptographically signed audit chains let you detect modification. SQL audit tables alone are weaker — anyone with DB access can rewrite history.
7 of 10 · audit
Can you export a signed audit bundle for any agent — covering its actions, permissions, and decisions — that a third party could verify offline?
Signed export bundles are how an external auditor or counterparty verifies what happened without privileged access to your database.
8 of 10 · trust
When your AI agent transacts with another company's system, can that counterparty verify your agent's identity without trusting your specific vendor (Microsoft, Google, AWS, you, etc.)?
Cross-org agent verification needs a neutral layer. Vendor-locked verification (Entra-only, Workload Identity-only) creates a single point of failure for every counterparty interaction.
9 of 10 · trust
Is your agent identity layer based on an open protocol (IETF draft, A2A v1.2 signed agent cards, etc.) — meaning you could swap implementations later without re-issuing every agent identity?
Closed-spec implementations migrate poorly. Open protocols (DNS, TLS, OAuth) keep your future optionality intact.
10 of 10 · audit
If you got paged at 02:00 about a suspicious agent action, could you query "which agent did this, with what permissions, on whose authority" and get a definitive answer in under 60 seconds?
Sub-minute incident query is the practical bar for production. If the answer is "wait, let me grep the logs and reconstruct," you do not yet have an identity layer — you have a forensics project.
0 of 10 answered