AI Agent Security Checklist for B2B SaaS: 18 Controls Before Production

Why agent security is different from ordinary application security

Traditional application controls still apply: secure authentication, input validation, tenant isolation, dependency management, logging and incident response. Agentic systems add a decision layer that interprets natural language, chooses among tools and may adapt a multi-step plan. The same content can be both useful data and an attack surface.

OWASP's 2026 agentic risk framework separates ten related failure modes: goal hijacking; tool misuse and exploitation; identity and privilege abuse; agentic supply-chain vulnerabilities; unexpected code execution; memory and context poisoning; insecure inter-agent communication; cascading failures; human-agent trust exploitation; and rogue agents. A control plan should cover the whole action path rather than treating prompt injection as the only problem.

OpenAI's current agent safety guidance likewise warns that prompt injection and private-data leakage remain risks even when mitigations are used. Its recommendation to constrain data flow with structured outputs is important because free-form text passed between components can carry instructions or sensitive data farther than intended.

• Source: who or what can influence the agent
• Decision: how the model interprets context and selects a next step
• Authority: which identity, tools and data the agent can use
• Sink: where information can be sent or an action can create impact
• Persistence: what is written to memory, records or downstream systems
• Propagation: how one result can affect another agent or automated process

Controls 1–3: define purpose, inventory authority and minimize privilege

Control 1 — Write a one-sentence operating purpose. Name the trigger, permitted outcome, systems in scope, prohibited actions, escalation owner and stopping condition. A goal such as help the sales team is too broad; classify an inbound enquiry, retrieve approved product facts and create a draft for review is testable.

Control 2 — Build an authority inventory. For every tool, record the credential used, data objects it can read, mutations it can make, external destinations it can contact, applicable tenant boundary and the person who owns access. Include browser sessions, MCP servers, file stores, email, calendars, CRM actions, code execution and agent-to-agent endpoints.

Control 3 — Replace ambient access with task-scoped access. Use separate service identities, short-lived tokens where the platform supports them, explicit scopes, tenant-aware authorization and deny-by-default tool registration. The model may request an action, but deterministic code must decide whether the authenticated user and agent are allowed to perform it.

• One role and one measurable outcome per agent
• No shared administrator credential
• Read-only access for discovery and pilot stages
• Per-tenant and per-user authorization enforced by the application
• Unused tools disabled rather than hidden in instructions
• Credential rotation and immediate revocation tested

Controls 4–6: separate instructions from content and constrain tool calls

Control 4 — Label provenance and trust. Preserve whether each item came from the user, an administrator, an internal system, a retrieved document, a public webpage or another agent. Do not concatenate these sources into one undifferentiated prompt and expect the model to infer authority reliably.

Control 5 — Use typed, minimal interfaces between the model and tools. Define allowlisted operations, required fields, enums, length limits and strict schemas. Validate tool arguments on the server and reject extra fields, malformed identifiers, cross-tenant references and free-form commands. Never pass model-generated SQL, shell commands or URLs directly to an execution layer without a purpose-built validator and containment boundary.

Control 6 — Treat tool responses as data, not new policy. Sanitize or normalize untrusted output, cap its size, block hidden instruction channels where practical and avoid feeding secrets back into the model unless the task requires them. Use an allowlist for outbound destinations and prevent arbitrary URLs from becoming an exfiltration path.

• Structured output between orchestration steps
• Server-side schema validation before execution
• Separate data fields from instructions and policy
• Destination allowlists for email, webhooks and network requests
• No secrets embedded in prompts, logs or tool descriptions
• Fail closed when provenance or required context is missing

Controls 7–9: put deterministic policy and human authority around impact

Control 7 — Classify every action by impact and reversibility. Reading a public help page, drafting an internal note, updating a customer record, sending an external message, changing access and moving money should not share the same approval policy. Require stronger evidence and review as impact rises.

Control 8 — Enforce policy outside the model. Apply spend limits, record-level authorization, rate limits, state-transition rules, duplicate protection and business invariants in deterministic code. A prompt that says never issue a refund above a threshold is weaker than an API that technically cannot do so.

Control 9 — Design meaningful approval. Show the reviewer the exact action, destination, important source evidence, changed fields and expected consequence. Do not ask for approval so frequently that reviewers learn to click through. Approval should occur immediately before the protected action and the submitted parameters should be bound to the approved request.

• Auto-run: low-impact, reversible and bounded
• Review required: customer-facing, financial, destructive or privilege-changing
• Prohibited: actions outside the defined purpose
• No hidden parameter changes after approval
• Two-person approval for exceptional high-impact actions
• Reauthorization when a plan or destination materially changes

Controls 10–12: protect data, memory and tenant boundaries

Control 10 — Minimize context. Retrieve the smallest data slice needed for the current task and redact sensitive fields before model use when they are not required. Separate customer tenants before retrieval, not after generation. Confirm the provider's current retention, training, regional-processing and deletion controls with the appropriate privacy and legal owners.

Control 11 — Govern memory as a database write. Define which facts may persist, who can write and correct them, their source, tenant, expiry and confidence, and which memories may influence high-impact decisions. Do not let one user, document or agent silently establish durable policy.

Control 12 — Defend against memory and context poisoning. Validate writes, isolate tenants and environments, retain provenance and version history, and create a review or quarantine path for suspicious updates. Test whether a malicious document in one session can alter later decisions after the original content is gone.

• Task-minimum retrieval instead of broad mailbox or drive access
• Tenant filtering before search and model context assembly
• Explicit memory schema, owner, provenance and expiry
• No long-term storage of secrets or raw credentials
• User-visible correction for consequential stored facts
• Backup, purge and recovery procedures for poisoned memory

Controls 13–15: secure the agent supply chain and multi-agent links

Control 13 — Maintain an inventory of models, prompts, tools, MCP servers, agent packages, data sources, evaluators and deployment configurations. Pin or approve versions where possible, verify publisher and update channels, review requested permissions and record changes that can alter behavior.

Control 14 — Authenticate agents and messages. Each agent or service should have a verifiable identity, an explicit audience and a narrow authorization policy. Sign or otherwise protect messages where the architecture requires it, validate schemas and prevent one agent from asserting that a user approved an action unless the receiving service can verify that claim.

Control 15 — Contain code and file execution. Avoid it when a narrower tool will work. If it is essential, use an isolated environment with resource limits, a restricted filesystem, no ambient secrets, controlled networking, safe file-type handling and automatic teardown. Treat generated code and dependencies as untrusted until scanned, reviewed and tested.

• Software bill of materials for agent components and connectors
• Approved registry for tools and MCP servers
• Change review for prompts, models, tools and permissions
• Mutual authentication and replay protection where agents exchange commands
• Sandboxed execution with explicit CPU, time, storage and network limits
• Rapid disablement of a compromised component

Controls 16–18: evaluate, monitor and recover

Control 16 — Create a versioned security evaluation set. Include normal tasks, incomplete requests, conflicting sources, indirect prompt injection, malicious tool output, cross-tenant identifiers, memory poisoning, privilege escalation, unreachable dependencies, duplicate actions and requests that require refusal or escalation. Measure both task success and policy compliance.

Control 17 — Record the action chain. Capture the authenticated actor, agent and configuration version, relevant input provenance, policy decisions, tool name, validated parameters, result status, approval evidence and final effect. Protect logs from unauthorized access and avoid storing unnecessary sensitive prompt content. Alert on denied high-impact actions, unusual destinations, repeated schema failures, privilege changes and rapid action bursts.

Control 18 — Rehearse containment and recovery. Provide a kill switch that stops tool execution without depending on the model. Document credential revocation, queue draining, memory quarantine, rollback, customer-impact assessment, evidence preservation and the owners who decide when service may resume. A graceful apology generated by the agent is not an incident response plan.

• Pre-launch adversarial testing against the real tool boundary
• Regression tests after model, prompt, tool, connector or policy changes
• Canary rollout with strict rate and impact limits
• Tamper-resistant action records and privacy-aware retention
• Kill switch and credential revocation exercised
• Post-incident review that updates controls and test cases

Map the checklist to the OWASP Agentic Top 10

The checklist is intentionally cross-cutting. Goal hijacking is reduced by separating authority from content, constraining data flow and testing adversarial inputs. Tool misuse, privilege abuse and unexpected code execution are constrained by least privilege, validated interfaces, deterministic policy and containment. Supply-chain, memory and inter-agent risks require inventories, authenticated communications, provenance and isolation.

Cascading failure is addressed by rate limits, action budgets, idempotency, circuit breakers and bounded rollout. Human-agent trust exploitation is reduced by evidence-aware approvals and interfaces that show what will actually happen. Rogue or persistently misaligned behavior requires monitoring, stop authority and recovery outside the agent itself.

A mapping does not prove that a system is secure. Use OWASP as a threat vocabulary, NIST's Govern–Map–Measure–Manage structure to assign ownership and evidence, and the controls of the specific model and platform as implementation inputs. Security review must be tailored to the agent's data, users, actions and legal context.

• ASI01 Goal Hijack: controls 1, 4–6, 16
• ASI02 Tool Misuse: controls 2–9, 17
• ASI03 Identity and Privilege Abuse: controls 2–3, 8, 14
• ASI04–05 Supply Chain and Code Execution: controls 13 and 15
• ASI06–07 Memory and Inter-Agent Communication: controls 10–14
• ASI08 Cascading Failures: controls 7–9, 16–18
• ASI09 Human-Agent Trust Exploitation: controls 7–9 and 17
• ASI10 Rogue Agents: controls 1, 16–18

A 30-day production-readiness plan

Days 1–5: freeze the agent purpose, owners and prohibited actions. Draw the data-and-action path, classify impact and complete the authority inventory. Remove every unnecessary tool and broad credential before doing more prompt work.

Days 6–12: implement the tool gateway, schemas, authorization, tenant isolation, outbound controls and approval policy. Make failures explicit and safe. Create the component inventory and document data retention, memory and deletion behavior.

Days 13–20: build the evaluation set from real workflows plus hostile cases. Run tests in an isolated environment, fix policy bypasses and verify that observability answers who did what, using which configuration, to which record and with what result.

Days 21–26: operate a canary in read-only, recommendation or draft mode. Measure accepted-task success, unsafe-action attempts, false approvals, correction effort, latency and cost. Review failures with the business, security and system owners.

Days 27–30: rehearse the kill switch and recovery runbook, approve remaining risk, set rollout limits and schedule the next review. Do not grant production write authority if the team cannot reliably detect a bad action, stop it and reconstruct what happened.

• Named business, security and technical owners
• Documented go, revise and stop thresholds
• No unresolved cross-tenant or privilege-control failure
• Approval tested with realistic reviewers
• Rollback and incident communications rehearsed
• Next review triggered by date and by material change

Launch gate and limitations

Launch only when the purpose and authority boundary are explicit, the application enforces least privilege and policy outside the model, consequential actions receive meaningful approval, hostile cases pass agreed thresholds, action records support investigation and the team has successfully exercised containment and recovery.

This guide is an implementation framework, not a penetration test, certification or legal opinion. The NIST AI RMF Playbook is voluntary and explicitly not a checklist that every organization should apply in full. Model behavior, platform controls and attack techniques change. Review the current primary sources, vendor documentation, contractual obligations and jurisdiction-specific requirements before production deployment.

• Pass: controls implemented and evidenced for the actual workflow
• Conditional: limited canary with compensating controls and a time-bound owner
• Fail: missing authorization boundary, tenant isolation, approval, logging or stop path
• Reassess after changes to model, prompt, tools, data, memory, permissions or autonomy