Securing AI agents: permissions, prompt injection and audit trails

A chatbot that only answers questions has a limited blast radius. An agent that reads your CRM, updates orders and sends email is different. It acts with real permissions inside real systems, and it takes instructions from text that anyone can write.

We treat every agent as a privileged user that can be talked into things. That framing drives the controls we build in from the start.

Give the agent the least access it needs

The most effective control is also the simplest: limit what the agent can do.

• Scoped credentials. Each agent gets its own service account with only the permissions its tasks require. A support agent that changes delivery addresses gets that permission and nothing broader.
• Narrow tools. We expose specific actions such as "look up order" or "update delivery address" instead of general database or API access. Each tool validates its inputs before anything reaches the backend.
• Acting on behalf of the user. When an agent works for a specific customer or employee, it inherits that person's access. A customer can only ever reach their own orders, whatever the conversation says.
• Limits on high-impact actions. Refunds above a threshold, bulk changes and anything irreversible need a person's approval.

If an agent is manipulated, these limits decide how much damage is possible.

Plan for prompt injection

Prompt injection happens when text the agent reads contains instructions it should not follow. The text can come from the user, but it can also hide in an email, a support ticket, a web page or a document the agent retrieves.

No prompt fully prevents this, so we design around it:

• Separate instructions from data. Retrieved content is passed to the model as data to reason about, and the system prompt says so explicitly.
• Check actions outside the model. The tool layer enforces permissions and business rules regardless of what the model asks for. A request to refund an order that does not belong to the customer fails in code.
• Watch what leaves the system. Outbound messages and links are checked so the agent cannot be used to send internal data to an outside address.
• Test it. Injection attempts are part of the evaluation set, and we run them on every release.

Protect the data the agent sees

Agents often need access to sensitive information to be useful. We decide early what data the model is allowed to see, mask fields it does not need, and keep personal data out of logs and prompts where possible. For clients with residency or compliance requirements, we choose model providers and hosting regions that meet them, and we document where every piece of data travels.

Keep an audit trail

Every agent run is logged: the request, the data retrieved, each tool call with its arguments and result, and the final response. When something goes wrong, the team can replay exactly what happened.

The same trail supports compliance work. Teams preparing for SOC 2 or similar reviews need to show who had access to what and which actions were taken. An agent with a complete audit trail fits into that evidence like any other system.

Monitor in production

Security does not end at launch. We set alerts for unusual patterns: a spike in refused actions, repeated attempts to reach other customers' data, tool calls outside normal hours or volumes. These signals often show an attack, or a gap in the agent's instructions, before it becomes an incident.

A checklist before launch

Before an agent goes live, we confirm:

• It runs with its own scoped credentials
• Every tool validates inputs and enforces permissions in code
• High-impact actions require human approval
• Injection and data-access tests pass in the evaluation set
• Sensitive fields are masked and data flows are documented
• Full audit logging is in place and searchable
• Alerts are configured and someone owns them

Security work adds time to the first release. It is also what lets a company give an agent real responsibility, which is where the value is.