I Found An Agent Running Under A Rotated API Key - Here's What KYA Finally Named
Last quarter I was digging through a provider dashboard looking for an unrelated bug when I noticed a service account still active under the API key of someone who had left the company in January. The account wasn't orphaned in any of the audits I ran. No alert fired. No one in our incident history had flagged it. It was just sitting there, calling endpoints on a schedule, billing charges to a credential attached to a person who no longer existed in the org chart.
That was an agent. I had deployed it six months earlier. I'd rotated off the feature. Nobody picked it up. Nothing in the system knew to page.
This morning a Bangkok fintech called MetaComp launched the world's first formal "Know Your Agent" framework at Money20/20 Asia. It was built for regulated finance. Firms that already have KYC and AML obligations for humans now need the equivalent for agents initiating payments, managing compliance calls, and rebalancing portfolios under their license. The release names the four things the framework covers: agent identity, authorization scope, monitoring, and accountability.
The name is the interesting part. The concept isn't new. What is new: the category I was post-morteming six months ago now has an acronym, a framework document, and the beginning of a cross-industry vocabulary. If you run agents outside fintech, you have the same problem. And you have no regulator coming to force the fix.
Here is what KYA looks like translated into non-regulated-enterprise terms.
Agents have deployment. Most don't have identity.
The one-minute test is brutal. Ask your own team, right now: which agent called that endpoint? If the answer takes longer than a minute to assemble from logs, config files, and tribal memory, you don't have Know Your Agent. You have Know Your Deployment. Those are different things.
Identity is the answer to four questions:
Who is this agent? Name it. Record what it's called, who deployed it, what version is in production, what decision it was built to make. An anonymous cron job is not an agent. It's a latent incident.
What is it authorized to do? An agent's scope should be strictly smaller than the scope of the human who deployed it. The reason most deployments invert that rule is that the fastest path to a working agent is "give it the admin key." Every production incident I've touched started in one of two places: admin-key scope, or stale permissions tied to a rotated employee.
Who sees what it did? Agents that log their own actions into their own memory are not audited. The audit record needs to live outside the agent: a different system, a different credential, ideally a different team owning the retention. Every incident retro I've sat in wanted this artifact and didn't have it.
Who is on the hook when it acts? One named human owner per agent. Not "the team." Not "whoever deployed it last." When that person rotates, the agent either gets a new owner or gets turned off the same afternoon. Orphan agents are to agent identity what orphan service accounts are to human identity: the attack surface that doesn't show up in any audit because nothing pages when they do something.
The fintech version is about to be mandatory. The rest isn't.
What MetaComp shipped is a regulatory on-ramp. MAS, FINRA, the SEC. They're all moving in the same direction. Regulated financial services will have a KYA-equivalent obligation in the next rule cycle, whether it's called KYA or something else.
The rest of the enterprise will not. No one is coming to require identity on the Zendesk-ticket-triage agent your customer support lead shipped last sprint. No one is coming to require authorization scope on the marketing-ops automation that posts campaigns under an admin OAuth token somebody generated in 2024. No one is coming to require audit trails for the product-analytics agent your growth team stood up against Segment last month.
The 2026 Cisco AI Security Index puts the readiness gap at 54 points. 83% of enterprises plan to deploy agentic AI. 29% feel ready to secure it. The missing 54 points aren't a tooling gap. They are an identity gap. No vendor closes it for you because the artifact is organizational, not technical.
What to actually do this week
Three concrete moves, cheapest to most expensive:
Day 1 exercise: list your agents. A literal spreadsheet. Every agent running against your infrastructure with name, purpose, owner, API credential, and the date that credential was last rotated. The first time I did this I found four agents nobody on my team could identify. Two of them were mine. One I'd forgotten about entirely.
Day 2 exercise: diff scope vs. deployer scope. For each agent in the list, write down what scope the credential has. Then write down what scope the person who deployed it has today. Not when they deployed it. The rows where the agent outscopes the current human are your inversions. Shrink them.
Week 2 exercise: separate the audit. Move the audit record out of the agent's runtime. A different system. A different credential. A different retention owner. The retrofit is tedious the first time. It's trivial after that. The first incident retro where it saves you pays for the whole week.
The PM artifact
What MetaComp actually shipped today wasn't a framework. It was a name. The people doing this work inside their own stacks already know what it looks like. The value of the acronym is that it gives the work a ticket title. A retro artifact. A category on a roadmap that isn't "miscellaneous AI hygiene."
For engineers: KYA is the identity layer for agents, the same way RBAC is the identity layer for humans. For PMs: KYA is the artifact you get to own before the first incident forces it. For solo builders: KYA is the four-question checklist you run before any agent touches production.
For the agent I found running under a rotated API key six months ago. The one I wrote the postmortem for. Today is the first day that postmortem has a category name.
Which agent on your team has one right now?
Source: MetaComp launches the world's first AI agent governance framework for regulated financial services
Top comments (1)
honestly, the "audit trail outside the agent" move breaks when you're orchestrating 4-5 agents that legitimately need shared working context. separating the audit starts duplicating the memory that makes the orchestration work. i underscoped that case.