Graig, Taina, and the Case for AI Agent Identity
Some of the operators in our repository history are not human. Graig and Taina are A-CX’s named AI personas, they hold accounts of their own, and the work they do carries their name rather than somebody else’s.
That is the argument of this post. AI agent identity is a security and audit decision rather than a branding exercise, and the shortcut most teams reach for first costs more than it saves. It is also worth being clear early about what these two are not allowed to do, because that turns out to be most of the interesting part.
Three Words We Use Precisely
These three get used interchangeably in most writing about agents, and the confusion makes the security question impossible to reason about. We keep them separate.
- AI agent. The thing that does the work. Our software delivery runs on a family of them, and we have others for the work around it. Agents hold no credentials.
- Operator. Whoever is operating our AI agents, and the holder of the permissions that work runs under. Either a human colleague or one of our AI personas.
- AI persona. A named AI identity at A-CX. Graig and Taina today. Each holds its own identity in the corporate directory, its own accounts on the systems it works in, and its own machine.
An AI persona is not a different kind of worker. It is a different kind of operator, filling the same role a human fills, under the same permission model, with no special case anywhere in the tooling. That symmetry is what makes the rest of this work.
How Graig and Taina Actually Work
Graig and Taina operate our delivery agents, the ones that take planned work through to merged code. That is the scope, and it is narrower than it sounds. Neither AI persona plans, and neither makes a detailed decision on its own without a human reviewing it.
The usual shape of a piece of work is that a human does the planning, often working with AI agents to do it, and an AI persona takes it from there. We have written before about why the planning is where the hours go, and that division has not changed because an AI persona is running the execution. Graig is the identity our overnight runs authenticate as, so work gets built, reviewed and merged while the team is asleep.
When an AI persona reaches something that needs a judgment call, it raises the question back to a human rather than deciding, and the work waits. That is the behavior we want and the one we check for. An agent that pushes through an ambiguity produces something confident and wrong, and confident and wrong is expensive to find later.
So there are two different limits operating at once, and you want both. The account bounds what an AI persona can do. The planning bounds what it should do. Last week’s post covered where an agent’s authority stops inside the process; this one is about the identity underneath it.
Almost No Agent Holds a Credential
Our delivery agents hold no identity, no token, and no access. They act as the operator who invoked them and inherit exactly that operator’s permissions. Run them as a person and they can do what that person can do. Run them as Graig and they can do what Graig can do.
There is one shape of exception and it is worth naming rather than pretending to purity. Where an agent has to act on a system that has no concept of our operators, it gets a dedicated account of its own, scoped hard. One of our content systems works this way: the account can create drafts and is refused at the API if it tries to publish or delete. That is a reasonable answer to a real constraint. A shared account that accumulated its permissions by accident is not the same thing, even though it looks similar from outside.
Either way the payoff is the same. Permission questions stop being prompt questions. Nobody has to write an instruction telling an agent which repositories it may touch, and nobody has to trust that the instruction survived a long context, because the account answers at the point of access the way it does for a human.
Why Not a Shared Bot Account
The common shortcut is one shared service account for all automation, or automation running on a senior engineer’s personal token because that was what was to hand when somebody needed it working. Both are faster to set up. Both cost the same three things.
- Attribution. With a shared account every automated change has the same author, and working out which process made a change becomes archaeology. With a borrowed personal token it is worse, because the history says a person did something they have never seen.
- Scope. Shared accounts accumulate permissions. Every new use adds one and nobody removes any, so the account quietly becomes the most privileged thing you own.
- Lifecycle. Revoking a shared account breaks everything at once, so it never gets revoked. Revoking an AI persona is the same operation as offboarding a colleague, which is a procedure your organization already has and already audits.
Underneath all three is a blast-radius argument. If an AI persona’s credentials are compromised the damage is bounded by what that one identity may do, and the response is the one you already rehearse for a compromised employee account. A shared automation account carrying years of accumulated permissions has no such boundary, and usually no owner either.
What Traceability Buys You
The test of an audit trail is which questions it answers without guesswork. Ours answers who made a change, whether the operator was a human colleague or an AI persona, what permissions were in force at the time, and which run the change belonged to. None of that needs logs correlated across systems, because the identity is the same object in each of them.
It also changes the conversation with a client. Naming the AI persona that touched a repository, and what it was permitted to do there, is a straightforward answer to a fair question. Explaining that a shared bot did it, on permissions nobody can enumerate, is not an answer anyone should accept, and we would not accept it from a supplier either.
The Part That Is Not Free
An AI persona is a real account with real access, and it needs the lifecycle discipline of one. Somebody has to own it, review what it can reach, and retire it when its work ends. A named identity nobody reviews is more dangerous than a shared bot, because it reads as governed when it is neither.
Worth saying plainly: giving software a name and a desk does not make it a colleague. Graig and Taina hold no judgment we have not delegated and no access we have not granted, and the things they are not allowed to decide are listed above rather than left to inference. We use names because people reason better about a named actor with a defined scope than about an anonymous process with an unexamined one.
Talk to Us
If you are running agents against your own systems and they authenticate as a person or as a shared account, that is the first thing we would change, and it is usually a shorter piece of work than it sounds. A-CX builds and runs AI Workflow Automation that is governed, observable, and still moving in production. Get in touch and we will start with who your agents are.
