The most dangerous part of an enterprise AI agent is not always the model. It is often the credential quietly attached to the tool call.

A chatbot can hallucinate and still be contained. An agent with a standing service-account token can hallucinate into production systems, customer records, billing workflows, ticket queues, source repositories, and internal documents. The difference is not intelligence. The difference is authorization.

That is why the next practical layer of agent infrastructure should look less like a shared service account and more like a lease: narrow, temporary, purpose-bound access issued for a specific task and revoked when the job is done.

This is not just a security slogan. The standards conversation is moving in that direction. NIST's 2026 concept paper on [software and AI agent identity and authorization](https://csrc.nist.gov/pubs/other/2026/02/05/accelerating-the-adoption-of-software-and-ai-agent/ipd) frames the problem directly: organizations need ways to identify, authorize, audit, and manage software and AI agents as they access data sets, tools, applications, and enterprise systems. Meanwhile, the Model Context Protocol draft [authorization specification](https://modelcontextprotocol.io/specification/draft/basic/authorization) maps HTTP-based MCP authorization onto OAuth-style roles: protected MCP servers act as resource servers, MCP clients act as clients, and authorization servers issue access tokens.

That is useful plumbing. But plumbing does not decide policy. Enterprises still have to answer the uncomfortable question: what should an autonomous or semi-autonomous agent actually be allowed to hold?

Why service accounts are the wrong default

Service accounts were built for deterministic software. A scheduled job, integration, or backend service needed stable access to a known system. The operating assumption was repeatability: the same code, same workflow, same permissions, same expected behavior.

Agents break that assumption. They interpret natural language, chain tools, read tool outputs, revise plans, and sometimes trigger actions the system designer did not enumerate clearly enough. Even a well-built agent can be steered by ambiguous instructions, stale context, hostile documents, or surprising tool responses.

A long-lived credential turns that uncertainty into standing privilege.

The usual failure modes are familiar:

  • nobody knows which human owner is accountable for the agent's access;
  • the credential has broader scope than the current task requires;
  • revocation is manual, slow, or politically painful because other workflows depend on it;
  • audit logs show that a token acted, but not why the agent requested the action;
  • a pilot becomes production without changing the identity model underneath it.

Okta's 2026 survey article, [AI Agents at Work](https://www.okta.com/newsroom/articles/ai-agents-at-work-2026-agentic-enterprise-security/), describes the operational gap. Okta reports that 92% of surveyed executives say autonomous AI agents are already in widespread or moderate use, while only 34% of organizations apply the same security controls to AI agents, bots, and automated systems as they do to human employees. It also reports that 58% of executives experienced an AI-related security issue or close call in the prior year.

Those numbers are not an argument to stop deploying agents. They are an argument to stop treating agent access as an afterthought.

What a credential lease changes

A credential lease is an access grant with an expiration date and a reason attached.

Instead of giving an agent a permanent key to the warehouse, the system issues a constrained credential for a specific job: summarize these documents, create this draft ticket, read this patient's scheduling context, update this one project record, open this pull request, or query this approved dataset. The credential carries the smallest practical scope, a short lifetime, a resource boundary, an agent identity, a human or system owner, and enough audit context to reconstruct the decision later.

A useful lease record should answer six questions:

1. Who requested access? The human operator, workflow, or upstream system. 2. Which agent acted? The named agent, version, environment, and policy profile. 3. What was granted? Tool, resource, operation, and scope. 4. Why was it granted? The task, ticket, case, prompt, or workflow state that justified access. 5. When does it end? Expiration, renewal rules, and revocation status. 6. What happened? Tool calls, outputs, side effects, and review events joined back to the lease.

That may sound like overhead, but it is the difference between "an agent did something with a token" and "this specific agent received a five-minute read-only grant to this resource because this approved workflow needed it."

The MCP draft specification's discussion of authorization challenges and scopes is relevant here. When protected resources can tell clients which scopes are required for a current operation, the client has a path to request the right access instead of asking for broad access up front. OAuth-style discovery and metadata help standardize the exchange. But the enterprise control pattern is the lease wrapped around that exchange.

The broker becomes part of the agent stack

In practice, credential leasing usually implies a broker.

The agent should not store durable secrets in its prompt context, workspace, or tool configuration. It should request access from a broker that knows the user's authority, the agent's policy, the workflow state, the resource sensitivity, and the organization's approval rules. The broker then issues a short-lived credential or denies the request.

For low-risk actions, the broker can approve automatically. For medium-risk actions, it can require stronger justification or narrower scope. For high-risk actions — payments, deletions, production changes, sensitive data exports, clinical actions, legal commitments — it can require explicit human approval or route the agent into a draft-only mode.

This pairs naturally with agent telemetry, but it is not the same thing. Telemetry tells you what happened. A credential lease constrains what can happen before the tool call leaves the agent boundary.

The OWASP agentic application risk framing reinforces the point. Agent systems face risks around tool misuse, unsafe chaining, identity, and privilege. Microsoft, summarizing the OWASP categories in the context of Copilot Studio, describes tool misuse as legitimate tools being used through unsafe chaining, ambiguous instructions, or manipulated tool outputs. If that risk is real, then the credential must assume the agent might be wrong at the worst possible moment.

Least privilege is not enough as a slogan. It has to become an issuance path.

A practical starting point

The easiest way to begin is not to rebuild every identity system. Pick one agent workflow that already touches valuable systems and remove its standing credential.

Start with a narrow pattern:

  • define the agent identity separately from the human who invokes it;
  • map the workflow's allowed resources and operations;
  • issue task-scoped credentials with short expiration;
  • log the lease ID on every tool call and resource access;
  • require reauthorization when the agent changes task, resource, or risk tier;
  • deny credential reuse across unrelated sessions;
  • make revocation boring and fast.

This approach also makes pilots more honest. A demo agent can look impressive when it has broad hidden access. A production-ready agent should prove it can work under the same constraints the business actually needs: scoped permissions, clear ownership, recoverable failures, and auditable decisions.

The future of agent authorization will include standards, protocols, and vendor platforms. Those matter. But the operating principle is simpler: do not let an AI agent carry a permanent badge just because your old automation did.

Give it a lease. Make the lease narrow. Make the lease expire. Make the lease explain itself.

That is how agent access becomes infrastructure instead of a liability waiting for the next prompt.

Sources

Build Agents That Prove Their Work

If you are wiring agent workflows into real operations, Alchemic can help design the checkpoints, traces, and validation gates that keep automation honest.

Get the Field Guide - $10 ->