Enterprise AI teams are entering a new operational phase.
OpenAI's current background-mode guide says background mode enables teams to execute long-running tasks on models like GPT-5.2 and GPT-5.2 Pro reliably, then poll response objects over time. Anthropic's current guidance on effective agents warns that autonomous agents can compound errors and recommends extensive testing in sandboxed environments. Its computer-use documentation goes further and says computer use requires a sandboxed computing environment, while also advising teams to isolate Claude from sensitive data and actions.
That combination matters.
Once AI workflows can run longer, call more tools, and operate across more systems, the security conversation shifts. The problem is not just whether a model should have tool access. The problem is how much access it gets, how long that access lasts, and what evidence survives after the run ends.
Too many teams still wire agent tools to persistent API keys, long-lived service accounts, and broad internal permissions. That is a demo shortcut. It is a weak production pattern.
The safer pattern is a credential lease: temporary, scoped access issued for a specific workflow, actor, tool, and time window, with clear expiration and a record of what the credentialed action actually did.
Why credential lifetime is now an AI workflow issue
Classic automation already cared about identity and access. Agentic AI raises the stakes because the system now decides more of the path at runtime.
The current Model Context Protocol authorization specification makes this clear. For HTTP-based transports, the spec defines an OAuth 2.1-based authorization flow. For STDIO transports, it says implementations should retrieve credentials from the environment. Its security section also says authorization servers should issue short-lived access tokens to reduce the impact of leaked tokens.
That is not abstract governance language. It is a practical warning.
If an AI agent can discover tools dynamically, carry work across long-running jobs, or resume after failure, then a standing credential becomes a standing blast radius. The more general-purpose the agent, the worse that blast radius gets.
NIST SP 800-207 makes the underlying principle explicit. Zero trust does not grant implicit trust based on network location. Authentication and authorization are discrete functions performed before a session to an enterprise resource is established, and zero trust focuses on protecting resources, services, and workflows rather than trusting a network segment.
In other words, the control boundary should sit around the resource and the session, not around a vague idea that “this internal agent is trusted.”
The stored-secret trap
Persistent credentials feel convenient because they remove friction during build-out.
- one secret works across many workflows,
- no token minting path needs to be built,
- the agent keeps working after retries or restarts,
- developers can debug without thinking about expiry.
That convenience hides four expensive production risks.
1. A leaked credential outlives the run that needed it
A stored key can be copied from logs, local config, prompt context, screenshots, crash dumps, or a compromised integration host. If it still works next week, the problem is no longer one failed run. It is ongoing access.
2. A broad credential collapses workflow boundaries
The same token may let an agent read documents, update tickets, trigger a workflow, and download sensitive records. That blurs the line between analysis, routing, mutation, and approval.
3. Retries become harder to reason about
If a job resumes with the same standing secret, teams often lose the chance to ask a more useful question: should this exact step still have access right now, under current conditions, with this same scope?
4. Post-incident review gets weaker
When many actions share one durable credential, it becomes harder to reconstruct which run, which operator, which workflow state, and which approval boundary actually authorized the action.
The better pattern: leased access
A credential lease is not a product name. It is an operating pattern.
The idea is simple: issue access as close as possible to the moment of use, bind it to the smallest practical scope, expire it automatically, and preserve enough evidence to review what happened later.
AWS documents the value of this model clearly. Its IAM guide says temporary security credentials are short-term and can last from a few minutes to several hours. After they expire, AWS no longer recognizes them. That is exactly the design direction enterprise AI teams should copy, even when the underlying systems are not AWS-native.
The point is not to mimic cloud branding. The point is to make agent access time-bounded, run-bounded, and inspectable.
The LEASE framework for agent access
A practical way to design this is LEASE.
L: Limit each credential to one narrow task envelope
Do not hand a general-purpose agent one broad secret for “the ERP” or “the document system.” Bind access to a single workflow lane such as read procurement exceptions, draft a case summary, or upload one prepared file to one staging location.
E: Expire by default
Access should die on its own. The MCP authorization guidance explicitly recommends short-lived access tokens, and AWS shows the same pattern with temporary credentials that stop working after expiry. If the run pauses for hours or resumes tomorrow, make the workflow request fresh access under fresh policy.
A: Attach access to actor, run, and approval state
The credential should be tied to a specific workflow instance and, when relevant, a human requester or approving operator. A token issued for draft-mode retrieval should not automatically authorize send, submit, or approve actions later in the flow.
S: Separate read, write, and approve rights
Many teams still bundle them together. That is where AI risk gets amplified. Read-only retrieval, draft creation, state mutation, and final approval should not share one permission shape. Anthropic's computer-use guidance to isolate sensitive data and actions is a useful principle here: the most consequential actions deserve the tightest boundaries.
E: Evidence every credentialed action
Keep the action ID, tool name, scope granted, issue time, expiry time, approval state, downstream response, and final observed result. Without that record, a “temporary” credential still leaves a durable blind spot.
Where credential leases matter first
Browser and portal agents
Computer-use workflows can interact with portals that were never designed as clean APIs. That makes them useful, but it also makes them risky. A browser agent gathering status from a supplier portal should not automatically inherit the same rights needed to submit a binding change. Separate collection from mutation and keep privileged actions close to a person.
MCP-connected internal tools
MCP makes it easier to expose internal systems to AI clients. That is powerful. It also means teams need a real authorization story for each server, each transport, and each token audience. If the client discovers a tool, that should not imply the client can exercise its most sensitive operations with a standing secret.
Private AI stacks
Local inference improves privacy and deployment control. It does not solve access governance by itself. A self-hosted model can still call internal APIs, read files, reach staging systems, or trigger downstream jobs. Private inference without leased credentials is still over-trusted automation.
A/E and technical review workflows
For VexASI-style document and review work, AI may help gather files, compare sources, classify issues, or prepare structured evidence. That does not mean the same workflow should hold persistent credentials for client release, signoff transitions, or external submissions. In technical review environments, the safest move is usually to keep high-consequence release steps human-controlled and separately authorized.
Questions technical buyers should ask now
- Which agent actions use persistent credentials today?
- What access could be replaced with short-lived tokens, session-bound credentials, or run-specific environment injection?
- Can the system separate read, draft, mutate, and approve rights cleanly?
- What happens if a long-running run resumes after the original approval context has changed?
- Can a reviewer see when access was issued, what scope it had, when it expired, and what action used it?
- Are browser tools, MCP servers, and internal APIs all governed by the same minimum standards for scope, expiry, and logging?
- Which workflows still assume that “internal” means trusted enough for standing credentials?
If those questions are hard to answer, the problem is not only security. It is workflow design maturity.
The commercial takeaway
Agent platforms will keep getting better at memory, planning, tool selection, and long-running execution.
That is the easy part of the sales story.
The harder and more valuable production story is whether the business can keep access narrow, temporary, and reviewable while those capabilities scale.
The strongest enterprise AI systems will not be the ones with the most standing secrets hidden in environment files.
They will be the ones that treat access like a controlled lease: requested for a purpose, granted with boundaries, expired automatically, and preserved in evidence after use.
That is how an organization keeps AI useful without quietly turning every capable workflow into a permanent credential holder.
Related reads
- OpenAI-Compatible Isn’t Agent-Compatible: The Protocol Checklist Every Private AI Stack Needs Before You Automate
- Prompt Injection Is Now an Operations Problem: Why Enterprise AI Needs a Quarantine Layer
- Long-Running AI Agents Need a Stop Policy: The Enterprise Guide to Safe Cancellation
- AI Workflow Services