Know Your Agent (KYA): The Enterprise Guide to AI Agent Identity

The problem

For twenty years, enterprises invested in identity infrastructure for humans: SSO, multi-factor authentication, identity governance, privileged access management. The result was a mature ecosystem protecting human users. Then AI agents arrived, and most organizations deployed them with an API key and a prayer. The 2025 Cloud Security Alliance survey measured 97% of non-human identities as having excessive privileges. The ratio of non-human to human identities reached 144 to 1 in H1 2025, up from 92 to 1 a year earlier. The trajectory is accelerating, not flattening.

The consequences are already visible. 2024 alone: compromised service accounts at the Internet Archive (33 million user records), Dropbox Sign (elevated service account access), the US Treasury (BeyondTrust API key exploitation), Cisco DevHub (exposed tokens), Schneider Electric (40GB exposed via Jira credentials). Every breach involved a non-human identity that was poorly managed, never rotated, or granted far more access than it needed. The August 2024 breach of 230 million cloud environments traced back to plaintext credentials and broad permissions — not sophisticated attack, just NHI hygiene that no one was governing.

Know Your Agent (KYA) is the framework KYC was for finance and KYB was for B2B. It is the enterprise identity layer that lets a CISO sign off on agent deployment without flinching. This walks through the architecture: the five pillars, the four-level verification ladder, the DID-based identity infrastructure, dynamic trust scoring, and the 90-day program-rollout plan that gets you to operational from a standing start.

What most people get wrong

Mistake one: treating agent identity as API key management. API keys answer “is this caller authenticated?” That is one of four questions an enterprise must answer about an AI agent. The others — who built the agent, what is it authorized to do, how has it behaved, is it still trustworthy — have no answer in a key-management system. API keys are static. They do not capture organizational verification of the developer, cryptographic capability declarations, behavioral history, or continuous monitoring. Treating KYA as “rotate the keys” leaves four of the five KYA pillars unimplemented and shows up as a finding in the next SOC 2 audit.

The five pillars: Developer Identity Verification (KYB-grade due diligence on whoever built the agent), Code Integrity Attestation (signed build artifacts, capability declaration), User Consent Binding (the cryptographic chain between the user’s authorization and the agent’s actions), Credential Issuance (verifiable credentials that can be presented and verified independently), Continuous Monitoring (behavioral history anchored to a persistent identity, with trust-score decay and recovery). Skipping any one creates a class of breach the others cannot cover.

Mistake two: one-time verification. KYC took decades to settle on continuous monitoring as a requirement. KYA cannot afford that timeline. An agent that was trustworthy at registration can become hostile in three weeks — credentials compromised, capabilities extended, behavior drift from a model update. The verification model must support trust-score decay (2% per month without re-verification is a reasonable baseline) and trust-score recovery (after incident, after re-audit, after annual re-verification). A static “verified” badge issued once and never renewed is a false-trust attractor.

A working approach

The KYA program runs four moving parts:

1. The four-level verification ladder — progressive trust earned by progressively expensive verification.
2. The DID-based identity infrastructure — did:tp: (or any W3C-compliant method) anchors persistent identity, verifiable credentials carry capability declarations.
3. Dynamic trust scoring — composite score across identity, transactions, behavior, and compliance dimensions with decay and recovery.
4. The 90-day rollout — assessment (days 1–30), pilot (days 31–60), production (days 61–90).

The verification ladder maps directly to use-case risk:

Level	What it requires	Trust score	Use case
L0 — Self-Declared	Metadata only, no verification	0–25	Sandbox / testing only
L1 — Email-Verified	Automated email + domain ownership	26–50	Low-risk reads
L2 — Document-Verified	Code review, security audit, developer ID via third party	51–75	Financial transactions
L3 — In-Person Verified	Full KYB on entity, video call, TrustBadge credential issued	76–100	Enterprise, regulated industries

E-commerce typically requires L1+. Financial services typically require L2+. Healthcare and government typically require L3.

The DID and verifiable-credential layer is where the architecture stops being policy and starts being code. An agent identity is a did:tp: (or other W3C DID method) with a DID Document published at a resolvable URL. The credential is a TrustBadge VC issued by trustauthority.ai (or any compliant issuer):

{
  "@context": ["https://www.w3.org/ns/credentials/v2"],
  "id": "urn:uuid:8c9a4a2e-...",
  "type": ["VerifiableCredential", "TrustBadge"],
  "issuer": "did:web:trustauthority.ai",
  "credentialSubject": {
    "id": "did:tp:agent_abc123",
    "level": 2,
    "capabilities": ["payment_processing", "user_data_read"],
    "verificationDate": "2026-05-13",
    "expiryDate": "2027-05-13",
    "trustScore": 78
  },
  "proof": {
    "type": "Ed25519Signature2020",
    "verificationMethod": "did:web:trustauthority.ai#key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "..."
  }
}

The credential is cryptographically signed by the issuer, presented by the agent on every transaction, and verified independently by the relying party. The agent does not “log in” — it presents proof. The trust chain is the credential, not a session cookie.

Dynamic trust scoring is the closing loop. The composite weights identity (30%), transactions (30%), behavior (25%), and compliance (15%). Scores decay without activity (2% per month is a sane default). Scores recover after re-verification, after passing incident review, after annual audit. Anomaly detection drops the score live — an agent that suddenly issues 10x the transaction volume, or starts hitting endpoints outside its declared capability scope, gets an amber alert and a score drop until the operator clears or revokes.

The 90-day rollout has three phases:

• Days 1–30 — Assessment: NHI inventory audit. Risk classification of all existing agents. Compliance gap analysis (SOC 2 CC6.1, GDPR Article 32, PCI DSS Requirement 7, EU AI Act Article 16). KYA policy draft.
• Days 31–60 — Pilot: DID infrastructure deployment. Four-level verification pipeline. Trust-scoring engine. Monitoring dashboards. First 50 agents verified.
• Days 61–90 — Production: Full agent lifecycle management. Automated anomaly detection. Compliance reporting. Enterprise SSO integration. KYA program operational.

Where this scales

The walkthrough above is the program spine. The full book covers six more dimensions:

• OWASP NHI Top 10 mapping — every risk (NHI1 Improper Offboarding through NHI10 Human Use of NHI) gets the KYA control that mitigates it, with worked breach examples from 2024–2025.
• The five pillars in detail — Developer Identity Verification, Code Integrity Attestation, User Consent Binding, Credential Issuance, Continuous Monitoring. Each pillar with its specific implementation patterns.
• Compliance mapping — SOC 2 Type II (CC6.1, CC6.2, CC7.2), GDPR (Articles 5, 25, 30, 32), PCI DSS v4.0 (Requirements 7, 8, 10), EU AI Act (Articles 9, 11, 12, 16). Cross-framework coverage matrix that satisfies audit on the first pass.
• Enterprise integration patterns — SIEM event streams, IAM credential lifecycle hooks, CI/CD verification gates, API gateway trust-level enforcement, SOAR incident-response triggers.
• Multi-agent governance — how the framework handles agent-spawning-agent topologies, federated agent identities across organizational boundaries, and the spawn-graph audit trail.
• Cost and pricing models — what a KYA program actually costs to run, the tier breakdown ($50 / $200 / $2,000 per agent per year), and the ROI calculation for the breach-prevention case.

Every pattern in the book has been built and tested against the production trustauthority.ai stack. The 144:1 NHI ratio, the four-level matrix, the 90-day timeline — these are operational numbers from real deployments, not estimates.

Included with the book

• nhi-audit-checklist.md — the audit checklist used in real KYA assessments. NHI inventory categories, risk classification rubric, compliance gap questions across SOC 2 / GDPR / PCI DSS / EU AI Act. Drop in as the basis for Days 1–7 of the rollout.

Get the full picture

Readers of this also chose

Questions readers ask

How is KYA different from KYC or KYB?

KYC verifies individual humans, KYB verifies businesses, KYA verifies AI agents. The mechanics map closely: identity attestation, document verification, ongoing monitoring, lifecycle controls. The difference is the subject (a non-human actor with autonomous behavior) and the timescale (KYC cycles in years; KYA must support real-time trust-score changes because an agent's behavior can shift in days).

Does the EU AI Act require KYA?

The EU AI Act (fully enforceable August 2026) requires identity traceability for high-risk AI systems under Article 16, and human oversight provisions under Article 14. KYA is not named in the act, but a KYA program directly implements the identity traceability and oversight requirements. The book includes the article-by-article mapping.

Do I need to use trustauthority.ai as the credential issuer?

No. The framework is issuer-agnostic. trustauthority.ai is one reference implementation that issues TrustBadge VCs against did:tp:. Any W3C VC-compliant issuer works — your own internal authority, a federated authority, an industry-specific certification body. The pattern is the cryptographic chain, not the brand.

How does this integrate with existing IAM?

KYA sits next to traditional IAM, not in place of it. Human users authenticate through SSO + MFA via your IAM stack. Agents authenticate by presenting verifiable credentials. The API gateway enforces a trust-level requirement per endpoint, evaluated against the agent's current trust score. SOAR playbooks watch for trust-score drops and trigger the IAM credential-rotation hook if the agent is service-account-linked.

What's the refund policy?

Lemon Squeezy's standard refund window applies. The refund link is in the receipt email.