Why KYA
The missing trust layer for AI agents acting in production.
AI agents can now trigger real-world actions: purchases, CRM writes, deployments. The core risk is simple — an agent acts with too much power, or outside policy, and you only discover it after damage is done.
The Problem#
Without a control gate, one bad call can:
- Execute an unauthorized purchase
- Push wrong data to your CRM
- Trigger an unsafe deploy
- Act beyond the intended scope with no audit trail
AI agents act like root users on your production APIs. They have no identity standard, no permission boundary, and cannot be audited or revoked safely.
The KYA Verify Gate#
KYA adds one decision point before every execution:
POST /verify
→ decision: ALLOW | DENY
→ reason_code: null | "SPEND_LIMIT_EXCEEDED" | ...
→ audit_event_id: "evt_01J..."Your app executes only on ALLOW. On DENY, you get a reason code you can log, handle, or surface to the user.
What This Gives You#
| Capability | What it means |
|---|---|
| Identity | Cryptographic proof of which agent is acting (Ed25519) |
| Permission control | Define exactly what each agent can do (tools, spend, rate) |
| Audit trail | Tamper-evident log of every decision with hash-chain integrity |
| Revocation | Stop a compromised agent or capability in seconds |
KYA vs. Traditional IAM#
Traditional IAM (Auth0, Okta) is designed for humans who log in once and get a session. AI agents operate differently — they act continuously, autonomously, and at machine speed. KYA is built specifically for this model:
| Human IAM | KYA (Agent IAM) | |
|---|---|---|
| Identity unit | User account | Agent (Ed25519 keypair) |
| Token model | Long-lived JWT session | Short-lived capability (5–30 min) |
| Scope | Per user | Per action |
| Revocation | Session invalidation | Seconds, capability blacklist |
| Audit | Login events | Every action, hash-chained |
| Policy | RBAC / ABAC | Per-agent tool + spend + rate limits |
KYA is the trust layer between agent intent and production action.