What Is an AI Agent?

Every argument about what counts as an AI agent eventually gets settled somewhere, and the place is never the architecture review. It is the identity console, at the moment someone has to decide what the thing is allowed to touch.

The demo goes well. A model reads an inbound request, works out what it is asking for, pulls three pieces of context from three different systems, drafts the response, and proposes the next action, all without a human touching the keyboard. The room is impressed, the slides land, and then the security architect — who has been quiet for forty minutes — asks the only question that will actually determine whether any of this ships: what account does it run under? Not which model, not how it plans, not whether it decomposes goals into subtasks. Whose credentials is it using when it opens that ticket, and if it does something unwise at two in the morning, what exactly do we turn off? The room usually does not have an answer, because the answer was never part of the pitch, and the meeting that was about capability quietly becomes a meeting about identity. That transition is not a digression. It is the moment the organisation begins treating the software as an agent, and everything before it was a product review.

The industry's definitions almost all run the other way. They are capability definitions, built out of a list of things the software can do: it can plan, it can use tools, it can hold state across a session, it can pursue a goal over multiple steps without being re-prompted, it can decide when it is finished. These are real properties and they are worth arguing about, but notice what happens when you try to use them at the boundary of an actual enterprise. Two systems with identical capability lists can sit on opposite sides of the line that matters — one runs inside a developer's sandbox, borrowing a personal token, invisible to every control the company owns; the other has a service identity of its own, a scope, an owner, an expiry, and a revocation procedure. The first is a demo no matter how impressive it is. The second is a participant in the organisation no matter how mediocre its planning happens to be. The definition that survives contact with a real company is the boring one: an AI agent is software that holds credentials.

Credentials are what make governance mechanical rather than aspirational

The reason this unglamorous definition does so much work is that an identity is not a label — it is a handle, and once something has a handle every governance question you care about stops being a philosophical problem and becomes an operation someone can perform on a Tuesday. Can we limit what it does? Yes, by scoping the credential to particular systems and particular verbs, which is the same mechanism that limits what a contractor can do, and which requires no new theory of machine intent to enforce. Can we stop it? Yes, by revoking, which takes seconds and does not depend on the software agreeing to be stopped or on anyone understanding why it behaved the way it did. Can we tell what it did? Yes, because the systems it touched recorded the identity that touched them, in the same tables and with the same retention as everything else. Can we say whose fault it is? Yes, because a credential has an owner, and the owner is a human being or a team with a name, which is what accountability has always actually meant in an organisation.

Every one of those answers is downstream of the same fact and none of them are downstream of capability. You cannot scope a system's reach by reasoning about how good its planner is; you scope it by what its token permits. You cannot revoke a set of behaviours; you revoke an identity. This is why the sophisticated debates about whether a given system is "really" agentic tend to feel unresolvable while the crude question — does it have its own account — resolves instantly and predicts almost everything else about how the deployment will go. It is also why the same piece of software genuinely changes category depending on how it is installed. Run it under a shared administrator credential that six people also use and you have not deployed an agent, you have deployed an untraceable extension of six humans, and no amount of autonomy in its reasoning loop compensates for the fact that the organisation has lost the ability to say who acted. Give it a principal of its own and you have added a party to the system, with all the obligations that follow.

Security engineering has had a word for this for decades and it is worth borrowing precisely because it is unromantic. A principal is any entity that can be authenticated and to which permissions can be granted — a user, a service, a process. The whole apparatus of enterprise control is built to operate on principals and on nothing else, which means the practical question of whether AI software is inside or outside your governance is identical to the question of whether it is a principal. Capability arguments describe how well a thing performs once it is inside. The credential is what puts it inside at all.

Most failed agent programmes fail on the identity, not the intelligence

This distinction has stopped being academic, because a large number of enterprise programmes are now discovering it the expensive way. Gartner has predicted that more than forty percent of agentic AI projects will be cancelled by the end of 2027, and among the reasons it names, alongside escalating costs and unclear value, is inadequate risk controls — the failure mode of a pilot that worked beautifully in a corner and could not be given a durable place in the estate. Anyone who has watched one of these cancellations up close will recognise the shape. The pilot is impressive, the business case survives scrutiny, and then production readiness turns out to mean answering a series of questions the project never framed: which systems it may reach, under what identity, reviewed by whom, revoked how, logged where, and rotated on what schedule. The intelligence was never the obstacle. The obstacle was that the thing had been built as a capability rather than as a principal, and retrofitting an identity model onto a system designed without one is close to rebuilding it.

The literature forming around the autonomous enterprise has been circling this same point from the operational side, and it lands in a place that will be familiar to anyone who has run a large IT estate: the hard part of putting non-human actors to work is not making them competent, it is making them accountable, and accountability is an identity problem before it is anything else. Notice, too, that the capability-first framing produces a bad procurement conversation. It invites vendors to compete on reasoning benchmarks and demonstration breadth, which are genuinely hard to evaluate and easy to stage, while the properties that determine whether the deployment survives its first incident — credential scoping, revocation, per-action attribution, separation between what the software may read and what it may change — are rarely on the comparison sheet at all. The buyer ends up with an excellent answer to a question that was never the risk.

Design the identity first and the architecture follows it

If you take the credential as the constitutive property rather than an implementation detail, the way you build changes in a specific and useful direction. Enterprise deployment stops being the last phase and becomes the first constraint, because the question of what identities exist, who owns them, and what each may touch is a design decision rather than a packaging decision. Connectivity gets designed as a permission surface rather than a convenience — which is much of the appeal of the Model Context Protocol, since a protocol boundary is a natural place to attach scope, and an agent that reaches its systems through declared, credentialed connections is one whose reach can be described in a sentence and changed without a rebuild. A gateway in front of the models stops looking like plumbing and starts looking like the place where usage is attributed and capped by identity. Human-in-the-loop stops being a safety slogan and becomes what it structurally is: a permission that was deliberately not granted, so that the action must route through a person who holds it.

This is the logic behind treating these systems as Autonomous AI Workers in the sense that platforms like StudioX use the term — not a claim about how humanlike the reasoning is, but a statement about how the thing is installed. Each specialist agent has an identity, a defined scope over enterprise knowledge and enterprise systems, an owner, and a set of decisions it is explicitly not authorised to make alone. The intelligence is what makes it useful; the credential is what makes it deployable, and the two questions should be kept firmly apart when evaluating anything in this category.

Which suggests a cleaner test than the ones the industry keeps proposing. Stop asking whether a system plans, or reasons, or acts without prompting, because those questions describe a spectrum and produce arguments nobody wins. Ask instead whether you could hand it a credential — whether it is the kind of thing that can be granted access, held to a scope, watched in a log, and switched off by someone whose name you know. If the answer is no, you have a very capable feature, and you should evaluate it the way you evaluate features. If the answer is yes, you have an agent, and you have just taken on a new member of the estate with all the unglamorous obligations that implies. Capability is its performance. The credential is its existence.