Should you let an AI agent onto your servers? How to grant access you can take back

Last updated: 3 July 2026

The first wave of AI agents suggested things. The next wave does them: it restarts a service, runs a migration against a production database, updates a DNS record, changes a setting in a live account. The moment an agent needs to act on a real system, the question stops being whether the model is capable and becomes whether you can grant it access you are able to scope, record and revoke. Most teams answer it the fast way, by handing the agent the same broad, standing credential a person would use. That is the mistake. Access designed for a human is the wrong shape for an agent.

We build and review agent systems, and the pattern is consistent. The guardrails inside the agent get attention, and the access around it does not. A team will spend a week tuning prompts and tool definitions, then give the finished agent a root secure shell (SSH) key or an admin token with no expiry and no separate record of what it did. That is the part that turns an ordinary mistake, or a single prompt injection, into an incident you cannot investigate. This article is about the access plane, not the model: how to grant an agent the access a task needs, in a form you can prove and take back. We have written separately about the controls that belong inside the agent loop, in how to build a reliable AI agent. This is the complementary half.

The real question is not capability, it is access

An agent that can only read is a very different risk from one that can also delete, deploy or pay. The capability of the model barely changes that calculation. What changes it is the set of permissions the agent is holding when something goes wrong, and something does go wrong, because an agent acts over many steps against systems that change underneath it.

OWASP (the Open Worldwide Application Security Project) gives this failure its own name in the Top 10 for large language model (LLM) applications: Excessive Agency, the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from a model [1]. It traces to three root causes, and two of them are about access rather than intelligence: too much functionality, too many permissions, and too much autonomy [1]. A capable agent with narrow access is safer than a mediocre one holding the keys to everything. Capability is what you buy from a model provider. Access is what you decide, and it is the decision that determines the blast radius when the agent is wrong.

Why a standing credential is the wrong default

The fast default is to give the agent a credential a human already has: an SSH key, a cloud administrator role, a database login, an application programming interface (API) token for a live account. It works immediately, which is exactly why it is dangerous. A standing credential with broad rights fails in three ways that a task-scoped one does not.

It converts a prompt injection into a breach. An agent that reads web pages, tickets, emails or files is executing instructions from whatever it reads. OWASP classifies this as prompt injection, and the indirect form is the one that matters for agents: external content the agent was sent to process can alter its behaviour in unintended ways [2]. If the agent can only read, an injected instruction is contained. If it is holding an admin credential, the same instruction is an insider with a master key. We cover the mechanics in prompt injection explained.

It leaks like every other secret. Long-lived credentials do not stay secret. GitGuardian recorded 28.65 million new secrets added to public GitHub commits in 2025 [3], and an agent's standing key is one more secret sitting in an environment file, a log line or a prompt, waiting to be exposed. A credential that expires on its own is worth far less to whoever finds it.

It leaves you unable to say what happened. When the agent uses a person's credential, its actions are mixed into that person's activity, if they are recorded at all. After an incident, you cannot separate what the agent did from what the human did, and you cannot prove either. The most expensive part of an agent failure is often not the action itself but the fact that you cannot reconstruct it.

What good access looks like

Access designed for an agent rests on four principles. None of them is new. They are the ordinary discipline of least privilege and auditability, applied to a non-human actor that most teams have not yet treated as one.

	Standing access (the fast default)	Governed access (designed for an agent)
Credential	a person's key or a long-lived admin token, shared with the agent	issued for one task, scoped to it, expires on its own
Scope	the broad rights the human happened to have	the narrowest permission the task actually needs
Irreversible actions	executed the moment the agent decides	proposed, then held for a human to approve
Record	mixed into a person's activity, if logged at all	every agent action recorded separately, tamper-evident
Revocation	rotate a shared secret, disrupting people too	withdraw the task's credential without touching anyone

Least privilege, scoped to the task

Give the agent the narrowest set of permissions the task in front of it requires, and nothing it might need for some other task later. OWASP's mitigation for excessive agency is exactly this: minimise the tools and apply least-privilege permissions so the agent holds only what the task needs [1]. The UK's National Cyber Security Centre (NCSC) frames the same rule for agents directly, advising teams to give agents only the minimum access they need, for the shortest time required [4]. This is the agent-shaped version of Zero Trust, which NIST (the National Institute of Standards and Technology) defines as granting access per request, with no implicit trust based on who is asking [5]. An agent should earn each grant, not inherit a standing one.

Short-lived credentials, issued per task

The credential should be created for a specific task and expire when the task is done, not sit in the environment indefinitely. Short-lived credentials shrink the window in which a leaked or misused secret is worth anything, which is the whole point of the NCSC's shortest time required [4]. In practice this means issuing a scoped token or a short-duration certificate at the start of a task and letting it lapse, rather than handing the agent a key it keeps.

A human gate on irreversible actions

Reading data can be automated freely. Actions that are hard to reverse, deleting, deploying, paying, sending, should be proposed by the agent and approved by a person before they run. OWASP is explicit that a human should approve high-impact actions before they are taken [1], and the NCSC offers a blunt readiness test: if you cannot understand, monitor or contain an agent's actions, it is not ready for deployment [4]. The agent proposes; a human disposes of anything you cannot undo.

A complete, attributable audit trail

Every action the agent takes should be recorded as the agent's, separately from the person operating it, in a form that cannot be quietly edited afterwards. This is what lets you answer, with evidence rather than a shrug, what the agent did and when. Traceability of this kind is one of the properties NIST's AI Risk Management Framework asks organisations to build in, so that AI systems can be monitored and held accountable rather than trusted on faith [6]. An audit trail is not paperwork. It is the difference between an incident you can investigate and one you can only apologise for.

The question a client, or an auditor, will ask

Sooner or later someone will ask the plain question: what did your AI touch on my system, and can you prove it. If the agent was using a shared human credential, the honest answer is that you do not fully know. That is not a position any engineering team wants to be in with a client, a regulator or its own board.

The underlying issue is that an agent is a new kind of identity. It is not a person, and it is not a traditional service account either, yet most organisations govern it as an afterthought to both. OWASP now maintains a dedicated Non-Human Identities Top 10 precisely because these machine actors, the tokens, service accounts and now agents that act on systems, have accumulated broad access with little oversight [7]. Treating an agent as a first-class identity, with its own scoped credentials and its own record, is what makes that plain question answerable.

This is a plane you design, not a setting you toggle

None of this arrives by default, and no model upgrade adds it. You can assemble it from primitives you already have: scoped tokens, short-lived SSH certificates, an append-only log, an approval step in front of the dangerous actions. But those parts do not connect themselves. Governed access is a plane, a layer positioned between the agent and the systems it acts on, through which every request is scoped, every action is recorded, and access can be withdrawn the instant a task ends or something looks wrong.

Teams that treat this as ordinary infrastructure, the same way they treat authentication for their human users, are the ones who can safely widen what their agents are allowed to do. Teams that skip it are the ones who will eventually give an agent access they cannot account for, and discover the gap at the worst possible moment. The good news is that this is engineering, not magic. It is designed the same way any access control is designed: deliberately, before it is needed, and reviewed by someone senior before it goes near production.

Frequently asked questions

Is it safe to let an AI agent access production?

It can be, but not with the access you would give a person. Grant the agent the narrowest permissions the task needs, issue a credential that expires on its own, require a human to approve anything irreversible, and record every action the agent takes in a separate, tamper-evident trail. A capable agent holding a standing admin credential is not a safe production setup, regardless of how good the model is.

What credentials should an AI agent use?

Short-lived, task-scoped credentials issued for the specific work in front of the agent, not a standing key or a shared human login. The credential should carry only the permissions the task requires and expire when the task is done, so that a leaked or misused secret is worth as little as possible and can be revoked without disrupting anyone else.

How do I know what an AI agent did?

Only if you recorded it as it happened. Every tool call and action the agent takes should be logged as the agent's own activity, separately from the person operating it, in a store that cannot be edited after the fact. Without that, an agent using a shared credential leaves its actions mixed into a human's, and you cannot reconstruct or prove what it touched.

Should an AI agent have the same access as a person?

No. A person's access is shaped by their whole role; an agent should hold only what its current task needs. An agent also behaves differently: it acts over many steps at machine speed and can be steered by content it reads through prompt injection. Both reasons argue for narrower, shorter-lived, more closely recorded access than you would give the person operating it.

Can an AI agent safely work on a client's system?

Only if you can scope, record and revoke what it does there. Before an agent touches a system you do not own, you need task-scoped access, a human gate on irreversible actions, and an audit trail you would be willing to hand to that client. If you cannot produce that record, you cannot answer the question the client is entitled to ask, and the agent should not be on their system.

Design the access before you grant it

If you are putting an agent anywhere near a system you cannot afford to lose, the access it is given deserves the same senior attention as the agent itself. Scoping what an agent may touch, putting the irreversible actions behind a human, and making sure every action leaves a record you could hand to a client or an auditor is the work we do on AI Agents. If you have already built it and want a second pair of senior eyes before it goes near production, that is a Vibe Code Audit, and we will tell you honestly where it stands. You can also read how we think about the controls inside the agent loop in how to build a reliable AI agent, why prompt injection makes an over-permissioned agent so dangerous, and what happened when we audited one of our own internal tools that held credentials it should never have kept.

We are also building this governed access plane as a product, so that scoping an agent's access, recording what it does, and revoking it are one deliberate step rather than a stack of parts you wire together yourself. It is in early access with a small number of teams who manage servers and agents on behalf of others. If that is you, you can join the early-access list.

Sources

1. OWASP, "LLM06:2025 Excessive Agency", Top 10 for LLM Applications 2025. https://genai.owasp.org/llmrisk/llm062025-excessive-agency/
2. OWASP, "LLM01:2025 Prompt Injection", Top 10 for LLM Applications 2025. https://genai.owasp.org/llmrisk/llm01-prompt-injection/
3. GitGuardian, The State of Secrets Sprawl 2026, 17 March 2026. https://blog.gitguardian.com/the-state-of-secrets-sprawl-2026/
4. National Cyber Security Centre, "Thinking carefully before adopting agentic AI", 15 May 2026. https://www.ncsc.gov.uk/blogs/thinking-carefully-before-adopting-agentic-ai
5. National Institute of Standards and Technology, SP 800-207: Zero Trust Architecture, August 2020. https://csrc.nist.gov/pubs/sp/800/207/final
6. National Institute of Standards and Technology, "AI Risk Management Framework". https://www.nist.gov/itl/ai-risk-management-framework
7. OWASP, Non-Human Identities Top 10. https://owasp.org/www-project-non-human-identities-top-10/