Let's start with a number that'll make you question every deployment you're currently running: 91% of enterprise AI agent deployments go live with insufficient prompt injection controls, according to the OWASP AI Survey from 2025. If you've been wiring tool access into an agent lately, there's a solid chance you're closer to that statistic than you'd like to admit—not because anyone's being reckless, but because most of us are still treating prompt injection as an input-validation problem when it's really an architectural constraint that demands infrastructure-level enforcement.

The Threat Model You Need to Internalize First

Here's the mental shift that changes everything: a prompt injection attack doesn't need your schema or a valid query. It just needs text somewhere your agent reads it—uploaded documents, retrieved web pages, API responses, database records, emails. Every data source your agent touches is a new injection surface. Beyond classic injection, you also need to track jailbreak via conversation history manipulation, tool abuse (APIs called outside intended scope), data exfiltration through output formatting tricks, privilege escalation through chained agent calls, memory poisoning in agents with persistent context, and supply-chain risk on the agent's own tool dependencies.

Control 1: Prompt Injection Prevention at Every Ingestion Point

Run detection at every content ingestion point—not just the chat box. That means user input, RAG-retrieved documents, API responses, emails, and database records each need channel-specific detection logic. The pattern is consistent: strip known injection patterns, classify risk using a dedicated classifier model call, apply source-specific trust levels (user input gets the lowest trust threshold, internal systems get higher ones), then wrap everything in explicit trust boundary markers before injecting into agent context. Route all detection events to security monitoring with real alert priority and retrain your classifier quarterly against new bypass techniques you're seeing in production—this control decays if you leave it static.

Control 2: Least-Privilege Access Design

Each agent should get the minimum tool, API, data, and system access its task requires—and this needs enforcement at the infrastructure layer, not just description in a prompt. Authorisation should be additive from zero, never exclusion-based; "everything except X" is a list you'll never keep current. Enterprises using least-privilege design from the architecture stage see 67% fewer agent security incidents according to deployment data from teams following this approach. Define an explicit agent manifest that maps every tool to scope, entities, rate limits, and approval requirements. Review before go-live and quarterly after, and explicitly block cross-agent permission inheritance.

Controls 3-4: Sandboxing and Real-Time Behavioral Monitoring

If something gets through your prevention controls, sandboxing is what keeps it contained. For code-executing agents, use ephemeral containers with no persistent filesystem, limited network to a whitelist only, and hard time/resource limits. Document-processing agents need read-only environments with no write access outside designated output stores. External API calls should route through a gateway that enforces the manifest and logs every call before forwarding. On the monitoring side: infra health metrics like CPU and latency won't catch an injection in progress—you need behavioral baselines established over two to four weeks of supervised operation covering tool-call frequency, sequence patterns, data access volume, and output content anomalies. Without this layer, injections sit undetected for 48 hours on average.

Controls 5-6: Audit Logging and Human-in-the-Loop Checkpoints

Every action needs an immutable record: timestamp, agent ID, session ID, input hash (never raw input—hash or redact PII per DPDP Act 2023), a structured decision trace, actions taken with parameters and results, output hash, and guardrail events. Write to a tamper-evident store separate from runtime infrastructure. If you're operating under CERT-In in India, the six-hour incident reporting window means these logs need real-time queryability—batch aggregation won't cut it. For human-in-the-loop: define consequence tiers before deployment (low = fully reversible, medium = reversible with effort, high = difficult or impossible to reverse), map every tool in your manifest to a tier, and route high-consequence calls through approval workflows with explicit timeouts. Unapproved actions get rejected, never auto-approved.

The Rollback Procedure Nobody Writes Until They're Improvising

Rolling back a compromised agent isn't the same as reverting a deploy—you need to address both the agent's state and whatever it already did downstream. Enterprises with pre-tested procedures contain incidents six times faster than teams improvising one live. Your procedure needs seven elements: an immediate isolation trigger (one action, before diagnosis), last-known-good state identification using version-controlled configs, action impact assessment via audit logs, data impact review driving DPDP/CERT-In notification decisions, a pre-written action reversal playbook per high-consequence action, root cause analysis plus verified patch before reactivation, and quarterly rollback tests in production-equivalent environments with measured max acceptable isolation time.

Who Owns What

This work tends to fall into the gap between security and engineering. A practical split: engineering owns the manifest implementation, sanitisation logic, audit log generation, sandbox configuration, and adversarial prompt testing. Security owns manifest sign-off, SOC integration, penetration testing, incident response playbooks, and compliance evidence. Both teams own consequence tier classification, baseline definition for monitoring, and post-incident root cause analysis.

Key Takeaways

  • Prompt injection is an architectural constraint requiring infrastructure-layer enforcement, not application-layer filtering
  • Least-privilege manifests should be additive from zero with explicit tool-to-tier mappings reviewed quarterly
  • Behavioral monitoring baselines require 2-4 weeks of supervised operation before go-live detection is reliable
  • Every action needs hashed (not raw) logging to a tamper-evident store for CERT-In and DPDP compliance
  • Pre-test your rollback procedure—incident containment is six times faster with documented runbooks

The Bottom Line

The uncomfortable truth in this guide is that most teams shipping AI agents today are doing exactly what the 91% statistic describes—treating security as configuration rather than architecture. If any of these six controls (injection prevention, least-privilege access, sandboxing, monitoring, audit logging, human-in-the-loop) is missing from your current deployments, that's the gap worth closing before you scale up usage. The good news? None of this is particularly complex to implement if you build it in from day one rather than bolting it on after something goes wrong.