The keys nobody signed for

The moment an agent goes into production, a new user shows up on your systems. Nobody interviewed it. Nobody assigned it a manager. It never sat through the security training, never got a badge photo taken, never had a role reviewed by anyone in IT. But it can now read records, call APIs, and act on the other side of your firewall, and somewhere in the rush to ship, a set of credentials got handed to it so it could get to work.

I ask the same question in most architecture reviews now, and it lands like an odd one: who is this agent, exactly, and what is it allowed to be? The answer, more often than not, is a shrug and a service account. A single set of keys, provisioned once, scoped generously so nothing would break during the demo, and shared across every run the agent ever makes. It works. That's the problem. It works so well that nobody goes back to ask what those keys can actually reach.

An agent is a user, and you skipped the onboarding

Enterprises already know how to think about people who can touch sensitive systems. You give a new hire a named identity. You grant the narrowest set of permissions the job needs. You review that access on a schedule, and on the day they leave, you switch it off. None of that is exotic. It's the ordinary hygiene that keeps a single compromised login from becoming a company-wide incident.

Almost none of that discipline gets applied to agents. An agent is not a feature you turned on. It's a principal that acts, and it deserves the same questions you would ask about any account that can move money, read a claim, or pull a personnel file. Instead it usually inherits whatever was convenient: a human's token borrowed for the occasion, or an application account with far more reach than the task in front of it ever required. The agent didn't earn that access. It was handed the keys because asking for less would have meant more work up front.

We wrote earlier about the blast radius of a helpful agent, how far the damage travels when a compromised agent is carrying your credentials. Identity is the thing that sets the size of that radius before anything goes wrong. A prompt injection against an agent scoped to one read-only dataset is an incident you contain by lunch. The same injection against an agent holding a shared account with standing write access to half the estate is the kind of morning that ends up in a regulator's inbox. Same attack. Different blast radius. The only variable that changed was what the identity was allowed to reach.

Borrowed credentials erase the story

There's a quieter cost to the shared service account, and it shows up long after the agent is running fine. When an agent acts under a borrowed identity, the audit log records the wrong actor. The trail says a human approved the payout, or that "svc-automation" touched the record, when what actually happened is that an agent made a call on a chain of reasoning nobody can now reconstruct. You didn't lose the log. You lost the ability to say who did the thing.

That is a strange failure to accept in the exact places we build for. Throughline, our investigations platform, exists to answer who did what and in what order. An agent that acts under a generic account and leaves "the system did it" in the record is the small version of the problem the whole platform was bought to solve. Attribution is not a nice-to-have you bolt on for the audit. It is the difference between an action you can explain to someone holding you accountable and an action you can only apologize for.

Every agent needs its own identity for the same reason every employee does. Not so you can admire an org chart of bots, but so that when something happens, the log names a specific principal, with a specific scope, acting under a specific policy, and you can trace the decision back without guessing. An action you can attribute is a control. An action you can only attribute to "automation" is a liability wearing a service account.

Least privilege is per task, not per agent

The reflex, once teams accept that agents need identities, is to give each agent one account with everything that agent might ever need. That's better than a shared god-mode token, but it still misses the point. An agent's access shouldn't be sized to everything it might do across its whole life. It should be sized to the step it is taking right now.

Take a sourcing workflow on MatryxAI. Over a full run the agent might read a supplier record, check a certification date, and draft a message. Those are three different reaches into three different systems, and there is no moment where the agent needs all three at once. Standing access to all of them, held for the length of the session, is a surface that exists purely for convenience. The pragmatic pattern is narrower: grant the read when the read happens, scope it to the record in front of the agent, let it expire, and grant the next thing when the next step arrives. Credentials that live for one task and then go away are credentials an attacker can't stockpile and a runaway loop can't compound.

This is the same instinct we bring to agent count itself. The fewer standing powers an agent holds, the smaller the set of things that can go wrong without anyone deciding they should. Least privilege isn't a posture you adopt to satisfy a checklist. It's the mechanism that keeps a helpful agent from becoming a versatile one in the wrong hands.

Treat non-human identity as a first-class citizen

The habit worth building is to stop treating agents as code and start treating them as a class of user with its own lifecycle. Non-human identities need the boring machinery that human ones already have: provisioning that assigns a named identity per agent, credentials that rotate instead of sitting in a config file for a year, revocation that actually cuts access the moment an agent is retired, and expiry so that access granted for a task doesn't quietly outlive the task.

Machines already hold more logins than people do in most enterprises, and agents will widen that gap fast. The teams that handle it well won't be the ones with a clever trick. They'll be the ones that decided early that an agent is an account, and accounts have owners, scopes, and end dates, and then held that line even when a shared token would have shipped a week sooner.

An agent you can't name in the log is not a smaller risk than a person with the same access. It's a bigger one, because it acts faster and never sleeps.

The test we actually use

Before an agent gets access to anything in one of our architectures, it has to clear a short list of questions. Does this agent have its own identity, or is it borrowing someone else's? What is the smallest scope that lets it finish the step it's on, and does its access expire when that step is done? If it's compromised at this moment, what exactly can it reach, and is that list one you'd be comfortable reading aloud to your regulator? When it acts, does the audit log name the agent, or does it name a generic account? And the day this agent is retired, is there one switch that turns its access off, or does its reach live on in places nobody remembers to clean up?

An agent that can't clear those doesn't get the keys. Not because we distrust automation, but because access you can't account for is access you've already lost control of, you just haven't found out yet.

Why the substrate carries the keys

The reason we can hold this line without slowing every project to a crawl is that identity doesn't live inside the agents. It lives in Neura-Cortex, the shared substrate underneath them, alongside guardrails, routing, human checkpoints, and the audit log. Identity and access are a platform concern, provided once and inherited by every agent in the portfolio, rather than something each new build reinvents under deadline.

That changes the default. When issuing a scoped identity, rotating a credential, and attributing an action are things the substrate already does, the easy path and the safe path stop being in tension. A team building on Clairant or MatryxAI doesn't reach for a shared token because scoping a proper one is friction. The friction is gone. What's left is an agent that shows up in the log by name, holding exactly the access its current step requires, and nothing it was handed just in case.

The most trustworthy agent I reviewed this quarter wasn't the most capable one. It was the one whose access you could describe in a sentence: its own identity, one dataset, read-only, expiring at the end of the run, every action logged under its own name. Nothing about it looks impressive on a slide. But when someone asks what it could do on a bad day, there's an answer, and the answer is short. That, and not raw capability, is what an agent you can actually put into production looks like.

---

MTekLabs designs, deploys, and governs production-grade agentic AI platforms for government and commercial enterprises. Our solutions are built human-in-the-decision-loop where it matters and auditable by design. Explore them at mteklabs.com.