Anyone can wire a language model to tools and call it an agent. The demo works. Then someone pastes the wrong thing into a chat box, the agent follows instructions it found inside a document it was summarizing, and it dutifully emails your customer list to an attacker, using the credentials you gave it.
Hardening is everything you do so that day doesn't happen. This is the checklist we work through before any agent we build or rescue touches production. None of it is exotic; all of it is regularly skipped.
What "hardening" actually means for an agent
An AI agent is a language model with an identity, tools, data access, and a runtime. You cannot make a text predictor behave, and hardening does not try. It builds the cage so that misbehavior, whether induced by an attacker or hallucinated spontaneously, cannot reach anything that matters.
The mental model that works: treat the agent as a clever, tireless, gullible contractor. You would not give a contractor your root credentials, unrestricted access to production, and instructions written on a sticky note. Everything below follows from that.
1. Identity: the agent is not your app
Give every agent its own service identity, not the application's identity or a shared "ai-service" account. This is the foundation every other control attaches to.
- One identity per agent (per environment). An agent that reads support tickets and an agent that issues refunds must not share credentials.
- Least privilege from day one: enumerate the specific resources each tool call touches and grant exactly those. "Read customer record by id" is a permission; "database access" is a liability.
- Short-lived credentials via workload identity: never a long-lived API key in the agent's environment, and never, ever a credential inside the prompt.
- Kill switch: one revocation should stop the agent cold. If disabling the agent requires a deploy, you don't have a kill switch.
2. Tools: authorize every call, not the agent
The agent's tool belt is your real attack surface. The pattern that survives contact with attackers is per-tool authorization:
- Each tool declares what it may touch, and each invocation is checked against the agent's identity by your infrastructure, not by the model's judgment.
- Validate tool arguments like hostile API input, because that is what they are. Schema validation, allowlisted values, bounded ranges.
- Split read tools from write tools. Reads can be broad-ish; writes are narrow, individually authorized, and logged with intent.
- Gate irreversible actions (payments, deletions, external messages) behind a policy check or a human approval. The agent proposes; the gate disposes.
- Log every execution with the conversation context that triggered it. When something goes wrong, "what did it do and why" must be one query, not an archaeology project.
3. Inputs: assume injection, because it's coming
Prompt injection is the default condition of an agent that reads anything from the world: documents, web pages, emails, other agents' output.
- Screen untrusted content before it enters the context window; strip or neutralize instruction-shaped text.
- Keep a hard boundary between instructions (your system prompt) and data (everything retrieved). The model won't maintain that boundary by itself; your scaffolding must.
- Treat inter-agent messages as untrusted input. Agent-to-agent injection, one agent's output steering another, is the multi-agent failure mode nobody tests for.
- Red-team it: your own team should be extracting secrets and triggering unauthorized tool calls in staging before someone else does it in production.
4. Data: what the agent never sees can't leak
- No secrets in prompts. The agent asks a broker for capabilities; it never holds keys.
- Scope retrieval to the requesting user's permissions; the agent must not become a lateral path to documents the user couldn't open directly.
- Filter outputs for credentials, personal data, and internal identifiers before they reach the user or another system.
- Decide retention deliberately: conversation logs are a data store full of whatever your users typed. Treat them like one.
5. Runtime: contain the blast
- Run the agent's execution environment, especially anything that executes code, in a sandbox with no default network egress. Allowlist the endpoints its tools genuinely need.
- Resource limits and timeouts on everything; an agent in a loop is a denial-of-service attack you built yourself.
- Rate-limit per user and per agent, on both requests and spend.
6. Monitoring: the part everyone defers
- Trace every action end-to-end (OpenTelemetry works fine; agents are just distributed systems with strange control flow).
- Alert on the behavioral tells: novel tool sequences, spikes in denied authorizations, outputs that trip your filters, unusual retrieval volume.
- Review denied-action logs weekly. Denials are your early-warning system: someone or something is probing.
The checklist
- Dedicated least-privilege identity per agent, short-lived credentials, kill switch
- Per-tool authorization enforced outside the model
- Tool arguments schema-validated; reads and writes separated
- Irreversible actions gated by policy or human approval
- Untrusted content screened before the context window
- Inter-agent messages treated as untrusted input
- No secrets in prompts; retrieval scoped to user permissions
- Output filtering for secrets and personal data
- Sandboxed execution, egress allowlist, resource limits
- Every action traced with triggering context; behavioral alerting live
- Injection red-team run against staging
If you can't check a box, you don't have a hardened agent; you have a demo with production credentials.
For the deeper treatment of the threat side (injection taxonomies, privilege escalation paths, real failure modes), read our companion guide, Securing AI Agents in Production. For the tooling stack that enforces each layer, see The Best Tools for Securing AI Agents in Production.
Stuck taking an AI system to production?
This is our whole job. InfoDive Labs is an engineering studio: senior engineers take systems the rest of the way: fix what's stuck, harden what's exposed, and stay on the pager afterwards. Every engagement starts with a call with the engineer who would do the work, not a salesperson.