Securing Production AI Agents: Identity, Permissions and Prompt-Injection Defence

Agent pilots are reviewed as software projects: model choice, prompt, evaluation set, licence cost. Almost nobody checks what the agent can reach. Then it goes live on a service account left over from the pilot, and the review that would have caught it never happens. The numbers explain the urgency. More than 50% of GenAI pilots are abandoned before they reach production, and the survivors tend to be the ones that found a governance owner early. Analyst guidance through 2026 points the same way: agentic AI governance cannot live in a policy document, because the failure mode is a live action, not a bad prediction. The question shifts from "what did the model say?" to "what did the agent do, with whose credentials, against which system?"

• The instruction surface. Anything the agent reads — a ticket, an email, a PDF, a retrieved knowledge chunk — can carry instructions. This is prompt injection, and no filter solves it.
• The identity surface. The credentials the agent runs under, how they are issued, how long they live, and whether one agent can impersonate another.
• The tool surface. The APIs, databases and file stores the agent can call, and whether those calls are scoped to the task or to the whole estate.

Most production incidents combine two of the three. A poisoned document plus an over-scoped token is enough to move money, leak records or delete a resource.

An agent should never be a shared service account with a static secret. It should be a first-class non-human identity with its own record, owner and lifecycle.

• One identity per agent, per environment. Production and staging must not share credentials, and neither should two agents with different jobs.
• Short-lived credentials. Tokens issued per run, minutes long, refreshed through a workload identity mechanism rather than stored in a config file.
• Delegated authority where a human is in the loop. When an agent acts for a user, the action should carry that user's authority and appear in their audit trail — not the agent's own superuser rights.
• Revocation that actually revokes. If you cannot kill an agent's access in one step, you do not control it. Test the kill switch before go-live, not during an incident.

Treat the identity record like a joiner-mover-leaver process: owner, purpose, review date and expiry. Agents accumulate permissions the way old accounts do, for the same reason.

Least privilege is an old idea that agents break in a new way: scope is decided at design time, then quietly widened every time someone adds a tool. Start from the task, not the system. A support agent that answers policy questions needs read access to a knowledge index and the ability to draft a reply — not write access to the customer record, and certainly not the billing API "for later". Write the permission set as a table with three columns: action, system, justification. A row without a justification is a future incident. Two constraints make this stick:

• Separate read from write, and write from delete. Read-only tools can be granted broadly and cheaply. Destructive tools should be narrow, logged, and gated by a second confirmation step.
• Scope by data, not just by endpoint. Row-level and tenant-level filters belong in the tool implementation, not in the prompt. A model instruction is a suggestion; a query predicate is a control.

If your back office is approaching end of support — SAP ECC maintenance ends in December 2027, and roughly 60% of the installed base has migrated — you will rebuild integrations anyway. Scope agent access then, not later.

The classic agent failure is not a jailbreak. It is an agent doing exactly what it was told, by the wrong party. An agent with send-email and read-inbox tools becomes an outbound channel after one crafted message. The defences are structural:

• Allow-list tools explicitly. No dynamic tool discovery in production. The agent gets the tools its job needs and nothing else.
• Never let retrieved content change the goal. Authorise each tool call against a fixed policy, not against whatever the agent claims it is doing.
• Log the reasoning trail. Store tool calls, arguments and retrieved sources per run. After an incident, this is the only artefact that explains what happened.
• Red-team before launch. Attempt injection through every input channel, including the boring ones: PDFs, CSV uploads, calendar invites and shared documents.

Controls that live in a design document do not survive a security review. The ones that do are enforced at runtime and produce evidence.

• Policy decision point. Every tool call is authorised against a policy engine that knows the agent, the user, the resource and the action.
• Immutable action log. Who or what acted, on which system, with which arguments, and what came back.
• Anomaly detection. A jump in tool calls, a new destination host or unusual data volume should page someone.
• Environment isolation. Sandbox anything that processes untrusted input, with no ambient credentials.

Security stalls when sequenced as a gate at the end. Put the controls in the platform instead — a shared agent runtime with identity issuance, a policy layer and logging — so each new agent inherits them by default. Start with the agent closest to production, map its tool calls, and remove everything it does not need. Over-scoped agents are also expensive agents, and the discipline is familiar from cloud estates, where 29% of cloud spend is wasted on resources nobody owns.