An AI agent can read a request, plan steps, call tools and change an external system. That combination turns a model error or manipulated instruction into a cybersecurity event. A misleading webpage can influence an agent, an overpowered service account can expose records, or a correct tool call can be executed in the wrong business context.

This does not mean companies should avoid agents. It means the security boundary must include the model, its context, identity, tools, memory, approvals and outputs. Traditional cybersecurity controls remain essential, but agent behaviour requires them to be applied at workflow level.

Start with a threat model for one job

Do not begin with “secure our AI.” Choose one workflow and document:

  • The business objective and expected output
  • Users and affected parties
  • Data read, created or changed
  • Models, tools, APIs and external content
  • Agent identity and credentials
  • Actions it can take and their impact
  • Human approval and recovery path

Then ask how confidentiality, integrity and availability could fail. Could the agent expose data, alter a record incorrectly, send an unauthorised message, execute malicious code, become unavailable, or create an action that cannot be reversed?

NIST’s 2026 analysis of responses on agent security reports broad agreement that agents create novel threats while established cybersecurity principles still matter and need adaptation. NIST has also highlighted identity, authorization, auditing, non-repudiation and prompt-injection mitigation as important areas for software and AI agents.

Give every agent a distinct identity

Do not let an agent act through a shared administrator account. Give each production agent a service identity linked to an owner, purpose and environment. Authenticate every call and authorize each tool action independently.

Use short-lived credentials where possible, store secrets in a managed vault and rotate them. Never place credentials in prompts, files or model memory. Separate development, test and production identities. Disable access automatically when the workflow is retired or the owner leaves.

An agent’s identity should be visible in downstream audit logs. A reviewer must be able to distinguish what the user requested, what the agent proposed, what a human approved and what the system executed.

Apply least privilege at action level

“CRM access” is too broad. Permit only the records and operations needed for the job. A support-drafting agent may read a limited customer record but should not export the database. A reporting agent may query approved views but should not change campaigns.

Start with read-only access. Add write permission for one reversible operation after testing. Use transaction, time, volume and cost limits. Restrict destinations and file types. Require step-up approval for deletion, publishing, payments, permission changes, external communication and other high-impact actions.

Do not rely on a prompt such as “never delete data” as the control. The tool layer must make deletion unavailable unless a separate authorized path approves it.

Treat retrieved content as untrusted

Prompt injection can appear inside webpages, emails, documents, tickets or tool results. The content may tell the agent to ignore its objective, expose secrets or call a dangerous tool. Because the instruction arrives through data rather than the user, a normal input filter may miss it.

Separate trusted instructions from untrusted content in the architecture. Label content by source, restrict which tool outputs can influence actions and require evidence from approved sources. Use allowlists and structured parameters instead of letting the model construct arbitrary commands or URLs.

Scan and sanitize files where appropriate, but do not assume a single detector solves prompt injection. Evaluate the complete agent against adversarial cases and design the system so a successful manipulation still encounters permission and approval barriers.

Constrain tools and execution

Wrap each tool in a narrow interface. Validate types, length, ranges, record ownership and business rules outside the model. Escape or parameterize database and command inputs. Run code in isolated environments without unnecessary network or filesystem access. Limit runtime, memory and spend.

Before execution, show the human approver the actual action—not a vague summary. “Send the attached proposal to these three addresses” is reviewable. “Continue workflow” is not. Bind the approval to the exact action so the agent cannot change parameters afterward.

For multi-agent systems, authenticate messages between agents, define which agent may delegate to which, prevent circular or uncontrolled task creation, and carry authorization context across handoffs.

Control memory and data leakage

Agent memory can preserve malicious instructions, sensitive content or outdated facts. Define what is stored, why, where, for how long and who can delete it. Keep tenants and environments isolated. Do not treat a model-generated summary as a safe substitute for the underlying sensitive data.

Redact unnecessary personal and confidential information before model calls. Prevent secrets in logs. Review connected tools, subprocessors and retention terms. Use egress controls where practical so a compromised workflow cannot send data to arbitrary destinations.

Monitor decisions and outcomes

Log user request, agent version, model, instruction version, retrieved sources, tool calls, approvals, results and errors with appropriate redaction. Create alerts for unusual volumes, destinations, permission failures, repeated retries, cost spikes and actions outside normal hours.

Measure more than blocked attacks. Track serious evaluation failures, unauthorized-action attempts, approval overrides, rollback use, time to detect, time to contain and repeated root causes. Review samples of successful runs because silent mistakes may not trigger an alert.

Prepare containment and recovery

Every production agent needs an owner, kill switch and manual fallback. Document how to revoke credentials, stop queues, isolate the environment, preserve evidence, notify affected owners and reverse changes. Test these steps before launch.

When an incident occurs, treat the model context, tool outputs, memory and connected systems as evidence. Fix the system boundary—not only the prompt. A new warning sentence will not repair excessive permissions or an unsafe tool interface.

A launch gate for agent automation

Approve production only when:

  • The workflow and threat model are documented
  • Agent identity and ownership are clear
  • Permissions are minimal and tested
  • Untrusted content is separated from authority
  • High-impact actions require exact human approval
  • Secrets, memory and retention are controlled
  • Adversarial and failure cases meet acceptance thresholds
  • Logs, alerts, kill switch, rollback and fallback are tested

Security review should repeat after changes to the model, prompt, tool, permission, data source or external interface.

AI agents can deliver useful speed, but authority should grow only with evidence. DEMA can help you choose a bounded workflow, design controls and define the operating metrics before deployment. Request a free growth audit or book a free consultation to automate with measurable value and controlled risk.

Sources