An agent that files an expense report has to be able to file an expense report, which means it needs an account in the expense system, and the account needs a password or a token or a certificate. This is the least interesting sentence in enterprise artificial intelligence and it is where a great many deployments are currently stuck.
The reason is that corporate identity was built around a premise the agent violates. An account belongs to a person. The person is hired, granted access appropriate to a role, reviewed periodically and eventually removed. Every control in the system — approval, attestation, revocation, the audit trail — hangs off that lifecycle.
The shortcut everyone takes first
In practice the first agent gets deployed under a human's credentials, usually the engineer who built it. It works immediately, which is the problem. The audit log now records that person approving invoices at three in the morning, their access review will confirm permissions they personally do not need, and if they leave the company the agent stops working in a way nobody will connect to the departure for several days.
The second attempt is a service account, which is closer and still wrong in a specific way. Service accounts were designed for a nightly batch job with a fixed, narrow scope. An agent's scope is not fixed — the useful ones need broad read access and the ability to take actions across several systems, and a single standing credential with that reach is exactly the object every security programme spends its budget trying not to create.
The direction the mature deployments have taken is to stop issuing standing credentials at all. The agent authenticates as itself, receives a short-lived token scoped to the specific task, and every action carries both the agent's identity and the identity of the human on whose authority it was acting. That last part is the one that resolves the governance question, because it restores an answerable version of who is responsible.
Building it is harder than describing it. It requires the downstream systems to accept delegated identity, which many enterprise applications simply do not, and it requires someone to own the mapping from business authority to token scope — a job that is neither security nor engineering and sits unassigned in most organisations. Companies that have solved it generally did so by naming an owner before they had a standard, rather than waiting for the standard to arrive.
The pressure is arriving from outside. Underwriters have begun asking how autonomous systems authenticate, in the same renewal questionnaires where they became the practical arbiters of corporate security practice. Buyers are pushing the requirement into vendor agreements alongside the other terms they have started to standardise across model contracts.
Which is a familiar shape. The consumer world has spent years replacing shared secrets with scoped, revocable, device-bound credentials, and that migration has been slow and uneven for reasons that have nothing to do with the cryptography. The enterprise is about to run the same project against a user population that multiplies weekly and never resigns.
