Rapid Launch: one fixed-scope AI workflow delivered in 24 hours See the package →

Security guide · Published August 7, 2026

AI agent security checklist for business

Short answer: a business AI agent should have a named owner, a dedicated identity, minimum necessary permissions, allowlisted tools, deterministic human approval for high-impact actions, audit logs, adversarial testing, continuous monitoring, and a tested shutdown and recovery path. Security must be enforced by the surrounding software—not left to the model’s judgment.

Published by Coding The Brains · Practical engineering guidance, not a certification or substitute for a security, privacy, compliance, or legal review.

The implementation checklist

Ten controls before production access

  1. 01

    Name an owner and a bounded purpose

    Document the workflow, intended users, approved inputs, expected outputs, prohibited actions, and person accountable for the agent.

  2. 02

    Use a dedicated agent identity

    Do not hide agent activity behind a shared administrator account. Give every action a traceable identity and, where relevant, the user on whose behalf it ran.

  3. 03

    Apply least-privilege access

    Start with no access. Add only the specific records, tools, and actions the workflow needs. Separate read, draft, approve, and execute permissions.

  4. 04

    Allowlist tools and action schemas

    Define which tools can run, the accepted parameters, range and type constraints, and the conditions that must be true before execution.

  5. 05

    Minimize data and memory

    Send only necessary context to models and tools. Define where data is processed, what is retained, who can retrieve it, and when it is deleted.

  6. 06

    Gate consequential actions

    Enforce approval in application logic for actions involving money, people, permissions, external messages, deletion, legal commitments, or other hard-to-reverse outcomes.

  7. 07

    Treat retrieved content as untrusted

    Validate tool inputs and outputs, separate instructions from retrieved data, and test indirect prompt-injection and data-exfiltration attempts.

  8. 08

    Log decisions and side effects

    Record identity, request, tools called, approvals, relevant outputs, state changes, errors, and correlation IDs without putting unnecessary secrets in logs.

  9. 09

    Evaluate before and after launch

    Test representative, edge, adversarial, and failure cases. Monitor production behavior, permission changes, exceptions, cost, latency, and outcome quality.

  10. 10

    Design revocation and recovery

    Provide a kill switch, credential rotation, access revocation, safe retries, idempotency where needed, rollback or compensation, and an incident owner.

Human approval

Set control by consequence, not by AI confidence

A confidence score is useful evidence, but it is not authorization. Put each action into a risk tier and enforce the rule outside the model.

Action tierExamplesDefault control
Read and summarizeRetrieve approved records, classify, summarizeScoped access, citations, logs, monitoring
DraftPrepare an email, report, ticket, or recommendationHuman reviews before external or material use
Reversible writeAdd a tag, create a draft record, update a low-risk fieldExplicit policy, validation, trace, easy rollback
Consequential actionSend externally, move money, delete, change access, affect a personDeterministic approval before execution

Ask the builder

Questions that expose a demo-only architecture

  • • Which identity does the agent use in every connected system?
  • • Can its read and write permissions be reviewed separately?
  • • Which actions require approval, and where is that enforced?
  • • Can every side effect be traced to an input, user, and version?
  • • What happens on a timeout, duplicate event, or partial failure?
  • • How do we disable it and revoke every credential quickly?

Collect the evidence

What a production handoff should include

  • • Architecture and data-flow diagram
  • • Tool, model, integration, and dependency inventory
  • • Permission and action-risk matrix
  • • Evaluation cases and recorded results
  • • Monitoring, alerting, and audit-log locations
  • • Incident, rollback, revocation, and ownership runbook

Use the AI agent architecture guide to place these controls around orchestration, context, model decisions, tools, and workflow state.

Primary guidance

Sources behind this checklist

FAQ

AI agent security questions

How do you secure an AI agent connected to business systems?

Give the agent a dedicated identity, only the minimum data and tools required for its task, deterministic rules around allowed actions, human approval for consequential actions, complete audit logs, tested failure paths, and a fast way to revoke access or stop execution.

Which AI agent actions should require human approval?

Require approval when an action is difficult to reverse or affects money, people, legal obligations, security settings, external communications, regulated data, or a system of record. Low-risk read or draft actions can often run with monitoring instead.

Can an AI agent use private company data safely?

It can be designed to reduce risk, but no architecture makes risk disappear. Limit access to approved sources, preserve existing user permissions, minimize retained data, review provider terms, filter sensitive outputs, log access, and test for prompt injection and unintended disclosure.

What does least privilege mean for an AI agent?

The agent receives only the identity, records, tools, and actions needed for its named workflow—nothing broader. Read access does not imply write access, and temporary elevated access should expire after the specific task.

What should an AI agent security review produce?

At minimum: a named owner, system and data inventory, permission matrix, action risk tiers, approval rules, test cases, logging requirements, incident and shutdown procedure, retention policy, and scheduled access review.

Start with one workflow

Need an agent that can survive a security review? Scope the controls with the workflow.

Show us the systems, data, actions, and consequences. We’ll define the permissions, approval points, tests, and recovery path before production access.