Identity and risk review for autonomous software.
Before an agent moves money, it goes through KYA — a structured compliance review that captures who controls it, what it can access, what it can spend, and whether a human supervises its decisions.
Why KYA
Six reasons agents need their own compliance layer.
An agent is not a person, not a company, and not a static piece of software. The review surface must reflect that.
Agents can be copied
The same model and prompt can run in many instances. Identity must be tied to authorisation, not artefact.
Prompts change
A small prompt edit can change behaviour materially. KYA records a hash so material drift is detectable.
Data sources matter
An agent's reasoning is only as trustworthy as the data it pulls. The list is part of the profile.
Spend authority matters
An agent given a $1M cap is a very different counterparty than one given $100. Authority is declared upfront.
Human oversight matters
A supervised agent and an autonomous agent need different review thresholds. The flag is explicit, not implied.
Risk profile is dynamic
Score is set at review and revisited. Frozen and revoked states exist for the cases that need them.
Profile
Eight fields. One agent record.
The KYA profile is the canonical record of what an agent is and what it's allowed to do. Reviewers can request changes; agents can re-submit with updates.
Schema mirrors the kya-service contract — see developer docs.
- Model
- Reasoning model identifier
- gpt-4o
- Vendor
- Provider of the reasoning model
- openai
- Purpose
- Plain-language scope of the agent
- Buys API credits for inference workloads
- System prompt hash
- Hash of the system prompt at submission time
- sha256:a1c4…b9e2
- Data sources
- External inputs the agent relies on
- ['internal-billing-api', 'stripe-balance']
- Human oversight
- Whether a human reviews actions before execution
- true
- Risk score
- 0–100, set by the reviewer
- 22
- Spend cap
- Maximum authorised spend across all proposals
- 50000 USD
Lifecycle
One state machine, six explicit states.
Every agent has a current state. Transitions are deterministic and recorded.
Draft
draftAgent is registered with the owner but not yet submitted for review. No spend authority.
Pending review
pending reviewSubmission sent to the KYA service. Reviewer fills in the profile and assesses risk.
Approved
approvedRisk profile accepted. Agent transitions to active and can create proposals.
Active
activeAgent is operating within its mandate. Every proposal still goes through policy + approval.
Frozen
frozenSpend paused. Owner or compliance can freeze without revoking — proposals are rejected.
Revoked
revokedTerminal. Agent loses authority. Resubmission requires a new registration.
Operator view
The reviewer's surface — designed for clarity.
A mock of the compliance dashboard. Each card is one submission awaiting a decision.
billing-assistant-v2
owner · acme.industries
- Model
- gpt-4o
- Cap
- 5,000 USD
- Risk
- 18/100
compute-scaler
owner · nimbus.dev
- Model
- claude-opus-4-7
- Cap
- 50,000 USD
- Risk
- 64/100
vendor-payer
owner · harborline.co
- Model
- gpt-4o-mini
- Cap
- 2,500 USD
- Risk
- 9/100
Mock view. The live operator surface is part of early access.
Bring your agents through the same gate humans go through.
KYA is open to integration partners shipping autonomous agents with real spend authority.