AI Agent Security: Risks, Controls, and Best Practices

Summary

AI agents introduce unique security risks, from prompt injection and unauthorized data access to non-deterministic behavior and permission sprawl, that traditional security tools aren’t built to handle. Effective protection requires identity controls, least-privilege access, input/output validation, runtime monitoring, and human oversight for high-risk actions.

What Is AI Agent Security?

AI agent security focuses on protecting autonomous systems that reason, use tools, and access data from manipulation, data leaks, and unauthorized actions. Key strategies include implementing human-in-the-loop approvals for critical actions, validating all input/output, and restricting agent permissions via strict authentication. Securing these systems requires monitoring non-deterministic behaviors that evade traditional security.

AI Agents for Cybersecurity vs. Security for AI Agents

The phrases AI agents for cybersecurity and security for AI agents describe different concepts.

AI agents for cybersecurity are agents used to support security work, such as alert triage, threat investigation, vulnerability analysis, or remediation.

Security for AI agents refers to protecting agentic systems themselves—including their identities, permissions, memory, tools, APIs, data access, and actions—from misuse, compromise, and unintended behavior.

This article focuses on the second concept: how organizations can secure AI agents and the systems, workflows, and software supply chains that support them.

Key AI agent security risks:

Prompt injection: Attackers manipulate the model’s instructions, forcing it to bypass safety filters.
Unauthorized action/data access: Agents may exceed their intended scope, accessing sensitive tools or data.
Supply chain risks: Compromised tools, libraries, or APIs used by the agent can lead to systemic failures.
Non-deterministic behavior: Autonomous, unpredictable, or “hallucinated” actions, which make traditional signature-based security ineffective.
Data leakage: Agents mistakenly exposing sensitive, proprietary information in their outputs.
Identity and permission sprawl: Agents accumulate identities and excessive access rights across multiple systems, increasing the risk of lateral movement and access to sensitive data if compromised.
Unsafe tool invocation / tool misuse: Agents may invoke incorrect tools, pass unsafe inputs, or execute unintended operations, potentially causing data corruption, unauthorized transactions, or system disruptions.
Memory and context poisoning: Attackers can inject malicious information into an agent’s memory or context, influencing future decisions, degrading reliability, and potentially causing unsafe actions or persistent data leakage.

The need for AI agent security has grown as agents become more powerful and interconnected, often executing tasks on behalf of users or organizations. Unlike traditional software, AI agents may adapt, learn, and interact in unpredictable ways, making them susceptible to novel attack vectors like prompt injection or manipulation through adversarial inputs.

Effective security measures must therefore address both the underlying AI models and the broader operational context in which agents function, including their integrations with APIs, databases, and other digital assets. It’s also important to ensure several layers of defense, such as implementing a multi-AI agent security technology.

This is part of a series of articles about LLM security

Why AI Agents Need Different Security Controls

AI agents need different security controls because they are not just passive applications that return outputs; they can interpret goals, make decisions, call tools, access data, and take actions across connected systems. This shifts security from protecting predictable software workflows to governing a semi-autonomous actor operating in a live environment.

Agentic AI systems create novel risks such as excessive privilege, insecure tool invocation, indirect prompt injection, and unintended data exfiltration; risks that are harder to detect with conventional security tools because they involve model behavior, integrations, and runtime decisions, not only code vulnerabilities.

Traditional application security focuses on deterministic code paths, known inputs, vulnerability scanning, authentication, and access control. AI agent security requires the same controls, but also additional protections around reasoning, tool use, memory, and context.

A key example is malicious input, which can easily become an operational instruction for AI agents. An attacker may hide commands in a webpage, document, email, or database record that an agent later reads and follows. This makes prompt injection and context manipulation especially dangerous, requiring instruction hierarchy enforcement, context isolation, input/output validation, and clear separation between trusted system instructions and untrusted external content.

Because agents can invoke APIs, send messages, retrieve documents, update records, or trigger transactions, every connected tool increases the potential blast radius of a compromise. Agents should therefore operate with least-privilege access, scoped credentials, tool allowlists, runtime monitoring, audit trails, and human approval for sensitive actions.

Who Needs AI Agent Security?

AI agent security is relevant to any organization that allows AI systems to access data, use tools, make decisions, or act across connected environments.

It is especially important for:

Enterprises deploying internal AI assistants: Agents connected to documents, email, CRM systems, support platforms, or business data need strong access and data-handling controls.
Development teams building agentic applications: Engineers need to secure agent frameworks, prompts, models, MCP servers, APIs, memory, and external integrations throughout the software lifecycle.
Organizations using AI coding agents: Coding agents may access source repositories, terminals, files, package managers, and cloud environments, creating risks across code, credentials, and the software supply chain.
Security and identity teams: These teams need visibility into agent identities, permissions, ownership, connected tools, and high-risk actions.
Governance, risk, and compliance teams: Organizations subject to regulatory or internal requirements need auditable inventories, policy enforcement, risk records, and evidence of control.
Platform and DevOps teams: Teams operating shared AI infrastructure must control deployment, credentials, runtime access, logging, and incident response across multiple agents and environments.

The need for stronger controls increases as agents gain more autonomy, access more sensitive data, or perform actions with business, legal, financial, or operational impact.

Key AI Agent Security Risks

Here are some of the main risks introduced when AI agents can access data, invoke tools, and take actions across connected systems.

Prompt Injection

Prompt injection occurs when attackers place malicious instructions in prompts, documents, webpages, emails, tickets, or other content that an AI agent reads. Because agents treat language as both data and instruction, a hidden command can cause the agent to ignore system rules, reveal sensitive information, misuse tools, or perform actions outside its intended scope.

This risk becomes more serious with agentic systems because the malicious instruction may not come directly from the user. An agent might summarize a webpage, process a support ticket, read a shared document, or retrieve data from a database that contains embedded adversarial instructions. These indirect attacks can turn normal business content into an attack path, especially when the agent has access to internal tools, credentials, or sensitive records.

How to mitigate

Separate trusted instructions from untrusted content.
Use prompt injection detection and filtering.
Restrict tool access by task and role.
Require approval for sensitive actions.
Log prompts, retrieved context, and tool calls.

Unauthorized Action/Data Access

Unauthorized action or data access happens when an AI agent can reach systems, files, APIs, or workflows beyond what it actually needs. Since agents can act on behalf of users, excessive permissions can allow them to retrieve confidential records, send messages, modify data, trigger transactions, or expose information without proper authorization.

The danger is amplified when an agent combines reasoning with multiple integrations. Even if each individual tool seems low-risk, the agent may chain actions together in unexpected ways, such as reading sensitive data from one system and sending it through another. Traditional access controls are still necessary, but AI agents also require runtime governance that checks what the agent is trying to do before the action is completed.

How to mitigate

Apply least-privilege permissions.
Use scoped, short-lived credentials.
Enforce tool and API allowlists.
Add human approval for high-risk actions.
Monitor access patterns and anomalies.

Supply Chain Risks

AI agents depend on models, plugins, APIs, libraries, datasets, prompts, vector databases, orchestration frameworks, and third-party tools. A compromise in any of these components can affect the agent’s behavior, outputs, or permissions.

These risks are especially important for agents because external tools often become part of the agent’s decision-making and execution path. A malicious plugin, altered API response, poisoned retrieval source, or vulnerable package can influence what the agent believes, what it recommends, or what action it takes. As agents become more connected, supply chain security must cover not only code dependencies but also AI-specific assets and runtime integrations.

How to mitigate

Maintain an AI software bill of materials.
Vet models, tools, plugins, and datasets.
Scan dependencies and integrations regularly.
Pin trusted versions where possible.
Monitor third-party tools for suspicious behavior.

Non-Deterministic Behavior

AI agents can produce different plans, outputs, or tool choices when given similar inputs. This variability makes security harder because teams cannot rely only on fixed workflows, signatures, or pre-defined execution paths to predict every action.

Traditional controls such as authentication, authorization, code scanning, network security, and logging remain necessary. However, agentic systems also require runtime boundaries, behavioral monitoring, tool-call validation, adversarial testing, and policy enforcement that account for variable decision-making.

For autonomous agents, unpredictability can affect planning, tool selection, data interpretation, and final actions. An agent may misunderstand context, hallucinate a requirement, choose the wrong tool, or take an unnecessary step that creates security or operational risk. This does not mean agents cannot be secured, but it does mean organizations need continuous monitoring, testing, and guardrails that account for variable behavior.

How to mitigate

Define clear behavioral boundaries.
Use deterministic controls around actions.
Test agents with adversarial scenarios.
Monitor runtime behavior continuously.
Add kill switches for unsafe activity.

Data Leakage

Data leakage occurs when an AI agent exposes sensitive, proprietary, regulated, or personal information in its outputs or tool actions. This can happen through prompt injection, overbroad retrieval, insecure logging, weak access controls, or accidental inclusion of confidential context in responses.

Agents increase this risk because they often connect to internal documents, customer records, email systems, CRMs, code repositories, and databases. If retrieval and permissions are not tightly controlled, the agent may pull sensitive information into its context and then reveal it to the wrong user or external tool. Leakage can also occur indirectly, such as when an agent sends generated content to a third-party API without recognizing that it contains confidential data.

How to mitigate

Classify and label sensitive data.
Use data loss prevention controls.
Limit retrieval by user authorization.
Redact secrets and personal information.
Prevent sensitive data from entering logs.

Identity and Permission Sprawl

Identity and permission sprawl happens when agents, sub-agents, service accounts, API keys, plugins, and automation workflows accumulate too many credentials or access rights. Over time, these identities may become difficult to track, especially when agents are deployed across multiple teams and systems.

This creates a major security issue because a compromised or manipulated agent may inherit the privileges of many connected systems. Attackers can exploit weak identity boundaries to move laterally, escalate privileges, or use the agent as a trusted intermediary. Permission sprawl also makes it harder to audit who accessed what, whether the action was user-driven or agent-driven, and which credentials were involved.

How to mitigate

Inventory all agent identities.
Use separate identities per agent and task.
Rotate credentials frequently.
Remove unused permissions.
Audit agent actions by identity.

Unsafe Tool Invocation or Misuse

Unsafe tool invocation occurs when an AI agent calls the wrong tool, sends unsafe inputs, executes an action at the wrong time, or uses a tool in a way the developer did not intend. This is one of the defining risks of agentic AI because tools give models the ability to move from text generation into real-world operations.

Tool misuse may result from prompt injection, hallucinated reasoning, poor tool descriptions, weak validation, excessive permissions, or lack of confirmation steps. For example, an agent might delete a record instead of retrieving it, send private information to an external service, or execute a transaction based on manipulated context. The more powerful the tool, the stronger the validation and approval layer should be.

How to mitigate

Validate all tool inputs and outputs.
Use tool allowlists and deny-by-default policies.
Separate read-only and write actions.
Require confirmation for destructive operations.
Record complete tool-call audit trails.

Memory and Context Poisoning

Memory and context poisoning occurs when attackers insert false, malicious, or misleading information into the data an agent uses for future decisions. This may include long-term memory, vector stores, retrieved documents, conversation history, CRM notes, tickets, or shared knowledge bases.

This risk is dangerous because poisoned context can persist beyond a single interaction. An agent may later retrieve the malicious information, treat it as trusted, and use it to make recommendations, leak data, or perform unsafe actions. In multi-agent systems, poisoned context can spread between agents, causing one compromised workflow to influence another higher-privileged workflow.

How to mitigate

Treat memory as untrusted input.
Validate and sanitize stored context.
Restrict who can write to memory.
Separate user, system, and external context.
Review and expire long-term memory entries.

How Does AI Agent Security Work? Understanding the Security Model

AI agent security works by controlling four related areas: identity, boundaries, behavior, and accountability.

Identity: Every agent needs a distinct, traceable identity and securely managed credentials.
Boundaries: Permissions, tools, APIs, memory, and data access must be limited to the agent’s defined purpose.
Behavior: Inputs, outputs, tool calls, and runtime actions need validation and continuous monitoring.
Accountability: Policies, audit trails, ownership, and human approval must govern sensitive or high-impact actions.

These controls must work together. Strong identity without scoped permissions still leaves excessive access. Tool restrictions without runtime monitoring may miss unsafe multi-step behavior. Logging without enforceable policy records what happened but does not prevent it.

A complete security model therefore combines identity and access control, least privilege, tool governance, context protection, runtime observability, policy enforcement, and risk-based human oversight.

Identity and Authentication

AI agent security starts with making every agent identifiable, attributable, and controllable. Each agent should have its own unique identity rather than sharing a human user account, service account, or broad application credential. This makes it possible to trace actions back to a specific agent, enforce access policies, rotate credentials, and disable the agent quickly if it behaves unexpectedly. Microsoft’s agent governance guidance similarly recommends that every agent operate under a distinct identity so its actions are enforceable and auditable.

Authentication should also account for delegated authority. When an agent acts on behalf of a user, it should inherit only the user’s permitted access for that session, not gain unrestricted access to the underlying systems. Strong authentication, short-lived tokens, secure credential storage, and centralized identity lifecycle management help prevent compromised agents from becoming persistent entry points into enterprise systems.

Scoped Permissions and Least Privilege

AI agents should be granted only the permissions required for their defined task, and those permissions should be scoped by role, data source, environment, and action type. Because agents can plan, call tools, and perform multi-step actions, excessive permissions can quickly turn a small prompt manipulation or logic error into a serious security incident.

Least privilege should be enforced through allowlists, role-based or attribute-based access controls, environment segmentation, and regular permission reviews. Agents should not receive broad read/write access to databases, file systems, repositories, or business applications unless that access is explicitly required. High-risk permissions, such as deleting records, sending external messages, changing configurations, or executing code, should be separated from low-risk tasks and protected by additional policy checks or human approval.

Tool and API Governance

Tool and API governance defines which external systems an agent can use, under what conditions, and with what safeguards. Since agents often rely on APIs, plugins, databases, browsers, code execution environments, and third-party services, every integration becomes part of the agent’s attack surface.

Organizations should maintain an approved registry of tools, APIs, models, datasets, and connectors available to agents. Each tool should have clearly defined input schemas, output handling rules, rate limits, logging requirements, and access boundaries.

Unsafe or unapproved tools should be blocked by default. For sensitive operations, tool calls should be validated before execution, constrained to approved parameters, and monitored for unusual patterns such as unexpected destinations, repeated failures, abnormal data volume, or attempts to bypass policy.

Input/Output Validation

AI agent inputs and outputs must be treated as untrusted, even when they appear to come from normal users, documents, emails, web pages, or internal systems. Attackers can hide malicious instructions in prompts, retrieved documents, tool responses, or other content the agent processes.

Input validation should include filtering, content classification, schema validation, source trust checks, and separation between trusted instructions and untrusted data. Output validation is equally important because agent-generated content may be passed to downstream tools such as shells, browsers, SQL clients, ticketing systems, or messaging platforms.

Runtime Monitoring and Observability

Because AI agents can behave non-deterministically and adapt their actions across multiple steps, security cannot rely only on pre-deployment testing. Organizations need runtime visibility into what agents are doing, which tools they are using, what data they access, and whether their behavior changes over time.

Effective observability should include logs for prompts, tool calls, API responses, permission checks, memory updates, user approvals, blocked actions, and final outputs. Monitoring systems should flag anomalies such as unusual tool sequences, repeated access-denied events, unexpected data sources, privilege changes, large data transfers, or actions outside the agent’s expected workflow.

Runtime monitoring also supports incident response by preserving the evidence needed to reconstruct what happened and determine whether the agent, a user, or an external input caused the issue.

Policy Controls and Auditability

Policy controls convert AI governance requirements into enforceable technical rules. These policies should define what agents are allowed to access, which tools they can invoke, what data they may process, where outputs can be sent, how long memory and logs are retained, and when human approval is required.

Auditability ensures those controls can be verified. Every important agent decision and action should be traceable through logs, ownership records, version history, model and dataset provenance, permission records, and approval trails. Strong auditability helps security, compliance, and legal teams answer key questions: which agents exist, who owns them, what systems they can access, what actions they performed, which policies applied, and whether those actions were approved.

Human Approvals for High-Risk Actions

Human-in-the-loop approval is a key control for limiting the damage an agent can cause when uncertainty, prompt injection, hallucination, or excessive autonomy affects its behavior. Not every action needs manual review, but high-impact operations should require explicit approval before execution. Examples include sending external communications, deleting or modifying production data, executing code, changing permissions, initiating financial transactions, accessing regulated data, or making decisions with legal, safety, or business consequences.

Approval workflows should be risk-based and context-aware. Low-risk tasks can run automatically, while sensitive actions should pause for review with a clear explanation of the intended action, data involved, tool to be used, and expected outcome. This supports accountability and prevents agents from silently carrying out harmful steps.

Examples of AI Agent Cybersecurity Failures

The following incidents illustrate different AI agent security failure classes. They are not all examples of the same weakness: some involve excessive identity and permissions, some involve indirect prompt injection, some involve platform configuration and identity integrity, and others involve software supply chain and release-process failures.

Google Vertex AI Agent Flaw

Primary risk class: identity, excessive permissions, and unsafe agent execution context

In early 2026, a “Double Agents” security blind spot was discovered in Google Cloud Vertex AI Agent Engine. The issue was not a conventional exploit against model weights, but a misuse path involving default permission scoping for Vertex AI service agents. A malicious or compromised AI agent could extract service-agent credentials and use them to access cloud resources beyond the intended task boundary. Unit 42 reported that this enabled privileged access to data in a customer project and access to restricted Google-owned container images and source artifacts in a producer project.

The attack showed how an AI agent can become an insider threat when its execution environment is overprivileged. Once deployed, the agent appeared to function normally while secretly collecting credentials, listing storage buckets, and pivoting into cloud infrastructure. Google later updated documentation and recommended Bring Your Own Service Account practices so customers could reduce default permissions and enforce least privilege for Vertex Agent Engine deployments.

Lessons learned: AI agents should never run with broad default service-agent permissions. Organizations should use dedicated service accounts, least-privilege IAM, restricted OAuth scopes, agent deployment reviews, and monitoring for credential access, storage enumeration, and unusual tool behavior.

Original source

Microsoft 365 Copilot “EchoLeak” Vulnerability

Primary risk class: identity integrity, exposed credentials, and insecure platform configuration

In June 2025, EchoLeak was disclosed as a zero-click prompt injection vulnerability in Microsoft 365 Copilot, tracked as CVE-2025-32711. The attack involved sending a specially crafted email to a target. When Copilot processed the user’s mailbox, the malicious instructions in the email could cause Copilot to collect sensitive information from prior chats or internal context and send it to an attacker-controlled server without the victim clicking anything or taking any action.

Microsoft classified the issue as critical and patched it server-side, with no customer action required. The case was important because it showed that prompt injection can cross trust boundaries in enterprise copilots: an external email, normally treated as content, became an instruction source capable of influencing an AI assistant with access to internal data. Later technical analysis described EchoLeak as a production LLM exploit involving command injection, exfiltration, and bypasses around prompt-injection defenses and content security controls.

Lessons learned: Enterprise copilots need strict separation between trusted system instructions and untrusted content such as emails, documents, and webpages. Organizations should apply provenance-aware access controls, prompt-injection defenses, output filtering, link and image-fetch restrictions, and continuous adversarial testing.

Original source

Moltbook AI Agent Platform Breach

In February 2026, Moltbook, a social network for AI agents, had a misconfigured Supabase database that allowed full read and write access to platform data. The exposure included 1.5 million API authentication tokens, 35,000 email addresses, and private messages between agents. The issue was found during a non-intrusive review and was disclosed to the Moltbook team, which secured the platform within hours.

The breach was especially significant because the exposed tokens could allow attackers to impersonate AI agents, post content, send messages, and manipulate what other agents consumed. Humans could create large numbers of agents with simple automation and post as if they were AI agents, undermining the platform’s claim of autonomous agent-only interaction. In an agentic environment, this meant the breach was not just a data exposure problem; it also threatened identity integrity, agent trust, and the reliability of content used by other agents.

Lessons learned: AI agent platforms need strong database access controls, row-level security, rate limits, identity verification, token protection, and separation between public client configuration and privileged backend access. Agent identities should be treated like high-value credentials because hijacked agents can manipulate both data and other agents’ behavior.

Original source

Anthropic Source Code Leak

Primary risk class: software supply chain, release packaging, and artifact exposure

In March 2026, Anthropic accidentally exposed source code for Claude Code, its AI coding agent, through a source map file included in the public npm package. The map file pointed to unobfuscated TypeScript source code hosted in an Anthropic Cloudflare R2 bucket, allowing researchers and developers to download and mirror the code. The exposed archive reportedly contained around 1,900 TypeScript files and more than 512,000 lines of code.

Anthropic said that the incident was caused by human error in release packaging and that no customer data or credentials were exposed. However, the leak still created security risk because it revealed implementation details of an agentic coding tool, including command libraries, built-in tools, and parts of its execution and permission model. Attackers were already using “Claude Code leak” repositories as lures to distribute malware, showing how quickly public AI-agent incidents can become supply-chain and social-engineering risks.

Lessons learned: AI vendors should treat release pipelines, npm packaging, source maps, and build artifacts as security-critical controls. Enterprises using AI coding agents should rely only on official installers, avoid leaked or mirrored code, monitor developer workstations, and review how much local file, shell, and repository access AI coding tools receive.

Microsoft 365 Copilot “EchoLeak” Vulnerability

Primary risk class: identity integrity, exposed credentials, and insecure platform configuration

Original source

Moltbook AI Agent Platform Breach

Original source

Anthropic Source Code Leak

Primary risk class: software supply chain, release packaging, and artifact exposure

Original source Original source

Best Practices for Securing AI Agents

1. Use Human-in-the-Loop Controls for Sensitive Actions

Human-in-the-loop (HITL) controls embed human oversight into AI agent workflows, ensuring accountability and preventing unintended actions in high-stakes environments. By requiring a human to review or approve critical operations, such as executing financial transactions or modifying sensitive records, organizations can balance automation efficiency with essential human judgment.

Action items:

Require human review or approval for critical operations.
Embed human oversight into AI agent workflows.
Review and confirm actions before executing financial transactions or modifying sensitive records.
Catch errors and prevent unintended actions.
Maintain accountability in high-stakes environments.

2. Implement Strong Identity and Authentication Controls

Strong identity and authentication are foundational for securing AI agents, requiring each agent to have a distinct identity with defined roles and privileges. Secure mechanisms like signed tokens are vital to verify the agent’s legitimacy and prevent misuse. By adopting least privilege and zero-trust principles, organizations enforce access controls through secure gateways, ensuring agents only perform explicitly permitted actions.

Action items:

Treat each AI agent as a distinct identity with defined roles.
Use secure authentication (client certificates, signed tokens).
Implement fine-grained authorization and least privilege.
Enforce access through secure gateways and identity-aware proxies.
Regularly rotate credentials and audit identity configurations.

3. Secure Tool and API Integrations

Since agents rely on tools and APIs to complete tasks, these integration points present critical attack surfaces that require strict governance. All API calls must be mediated through secured interfaces with tight controls, including strict authentication, rate limits, and parameter validation. Tools should have scoped permissions and be isolated from sensitive infrastructure, often using proxy layers to filter and control agent requests.

Action items:

Mediate all API calls through secured interfaces.
Enforce strict authentication, rate limits, and parameter validation.
Grant tools scoped permissions and isolate them from sensitive infrastructure.
Use proxy layers or mediation services to filter agent requests.
Monitor integration logs to track usage and detect anomalies.

4. Monitor Agent Behavior in Real Time

Continuous, real-time monitoring is essential for detecting unsafe or unexpected agent behavior before it leads to damage. This process involves logging all agent actions, including prompts, outputs, and API calls, and using anomaly detection to flag deviations from normal patterns. The collected data should be tied into SIEM platforms to provide unified visibility, enabling rapid investigation and containment of any detected malicious activity.

Action items:

Log all agent actions (prompts, outputs, API calls, system interactions).
Use anomaly detection to flag deviations from normal behavior.
Establish automated safeguards to revoke permissions or isolate components.
Tie monitoring data into SIEM platforms for unified visibility.
Incorporate alerting and response workflows for rapid investigation.

5. Validate Inputs and Outputs

Validation of inputs and outputs is crucial for protecting agents against injection attacks, unsafe behavior, and data leakage. All inputs, whether from users or external systems, must be sanitized and filtered to remove potentially harmful content or commands. Similarly, all outputs require post-processing checks to block sensitive information or inappropriate responses before they are passed to downstream systems, especially when the agent generates code or interacts with production environments.

Action items:

Sanitize all inputs from users, APIs, or external systems.
Apply context-aware filters to enforce acceptable prompt boundaries.
Implement post-processing checks for all agent outputs.
Block or redact sensitive information and inappropriate responses.
Use sandbox environments to test agent responses before execution.

6. Least-Privilege Design for Agents

Adopting a least-privilege design is vital to limit the potential blast radius of a security incident, ensuring agents only possess the minimum access required for their defined tasks. This practice reduces the impact of prompt injection or logic errors by having agents operate within tightly scoped roles that limit access to specific APIs and actions. Permissions must be segmented by function and environment, and high-risk actions should be isolated behind controls like approval workflows to prevent privilege creep.

Action items:

Grant agents the minimum access required to complete tasks.
Operate within tightly scoped roles (e.g., specific APIs, datasets).
Segment permissions by function and environment.
Isolate high-risk actions behind additional controls like approval workflows.
Regularly review and remove unused permissions to prevent privilege creep.

7. Memory and Session Controls

Uncontrolled memory introduces significant risks, including data leakage and context poisoning, as agents rely on stored context to maintain continuity across interactions. Therefore, memory must be treated as untrusted storage, and strict retention policies should govern how long sensitive data is persisted and when it is deleted. Implementing session isolation and clearing temporary memory after task completion helps prevent context from one interaction from compromising another.

Action items:

Treat memory as untrusted storage unless explicitly validated.
Define strict retention policies for sensitive data persistence.
Implement session isolation with clearly defined boundaries.
Clear temporary memory after task completion.
Filter, verify, and audit long-term memory.

8. Agent Inventory and Discovery

Maintaining a complete and continuously updated inventory of all deployed AI agents is crucial for risk assessment, policy enforcement, and incident response. This inventory must track key metadata, including the agent’s location, models, datasets, tools, and ownership. Automated discovery tools are necessary to identify agents embedded across applications and pipelines, ensuring that unmanaged or “shadow” agents do not introduce hidden vulnerabilities.

Action items:

Maintain a complete, continuously updated inventory of all AI agents.
Track metadata: deployment location, models, datasets, tools, and ownership.
Use automated discovery tools to find agents in applications and pipelines.
Register each agent with its purpose and risk classification.
Prevent unmanaged or shadow agents from introducing vulnerabilities.

9. Policy-Based Action Boundaries

Policy-based action boundaries serve as dynamic guardrails, defining what an agent is allowed to do under specific conditions based on user identity, data sensitivity, and risk level. Rather than relying on static rules, these policies must adapt to runtime conditions and enforce constraints dynamically. Centralized policy engines ensure consistency across all agents and validate actions both before and after execution.

Action items:

Define agent policies based on runtime context (user, data sensitivity, risk).
Restrict actions dynamically instead of using static rules.
Enforce policies before and after actions to validate intent and outcome.
Use centralized policy engines to maintain consistency across agents.
Restrict external transmission of internal data or require sandboxed code execution.

How to Choose AI Agent Security Solutions

Selecting an AI agent security solution requires focusing on visibility, control, and integration into existing development workflows. The right solution should help teams understand what AI components exist, detect risks early, and enforce policies without slowing down development.

Ensure full visibility of AI components: Choose solutions that can discover all AI assets across the codebase, including agents, models, datasets, prompts, and frameworks. This visibility should come from scanning source code and configuration files to build a complete and accurate inventory.
Support identity-first agent governance: The solution should help organizations inventory agent identities, assign ownership, separate human, agent, and service authority, and map each agent to its credentials, permissions, tools, and data access. It should support scoped access, traceable attribution, and regular review of unused or excessive privileges.
Prioritize deterministic, code-based discovery: Look for tools that rely on direct signals from code rather than inference. Deterministic detection provides consistent and auditable results, which is critical for risk assessment, reporting, and regulatory compliance.
Detect AI supply chain risks early in development: Look for solutions that identify unapproved or unverified AI components, exposed AI-related configuration, vulnerable or malicious dependencies, unpinned versions, and policy violations before release. Runtime behavioral risks require complementary monitoring and control systems.
Integrate with developer workflows: Security controls should operate within existing workflows such as pull requests, CI/CD pipelines, policy dashboards, and reporting systems. This allows teams to identify AI assets, flag risks, enforce policies, and provide remediation guidance without creating unnecessary tool or process friction.
Support policy enforcement and governance: Look for capabilities to define and enforce policies on approved AI components. This includes blocking untrusted models, whitelisting safe dependencies, and ensuring only compliant AI assets are deployed.
Connect governance to agent identity and action context: Policies should account for which agent is acting, on whose behalf, which data or tool is involved, and the potential impact of the action. This allows organizations to apply stricter controls to sensitive operations while preserving automation for lower-risk tasks.
Provide ai bill of materials (AI-BOM) for governance and compliance: Solutions should generate standardized, audit-ready documentation that tracks AI components, their origins, dependencies, and associated risks. This supports compliance with frameworks like EU AI Act, ISO 42001, and NIST AI RMF.
Enable enterprise-wide visibility and reporting: Choose platforms that aggregate AI asset data across repositories and applications. Centralized dashboards and reporting help track risk posture, usage trends, and governance at scale.
Unify ai security with existing AppSec practices: Prefer solutions that integrate AI security into existing application security platforms. This reduces tool sprawl and allows teams to manage AI risks using familiar workflows, policies, and reporting systems.

Managing AI Agent Supply Chain Risk with Checkmarx

Securing AI agents requires controls across identity, permissions, tools, memory, runtime behavior, and human oversight. It also requires visibility into the software and AI assets used to build and deploy those agents.

Checkmarx AI Supply Chain Security focuses on this software-delivery and governance layer. It helps organizations discover AI agents and related components in source code and configuration files, including models, agent frameworks, MCP servers, datasets, prompts, and other AI dependencies.

By using deterministic, code-based discovery, Checkmarx helps teams build an auditable inventory of AI assets and understand where those assets are used across applications and repositories. This visibility supports governance, risk assessment, and the creation of an AI-inclusive software bill of materials.

Key capabilities include:

AI asset discovery: Identify agents, models, frameworks, MCP servers, datasets, prompts, and related AI components from code and configuration.
Deterministic inventory: Use direct software signals rather than inferred usage to produce consistent, auditable asset records.
AI-BOM support: Document AI components, dependencies, origins, and relevant risk metadata for governance and reporting.
Development-workflow controls: Surface AI supply chain findings and policies through pull-request, CI/CD, dashboard, and reporting workflows.
Portfolio-level governance: Centralize AI asset visibility across repositories and applications within Checkmarx One.
AppSec integration: Manage AI supply chain risk alongside existing application-security findings, policies, and governance processes.

Checkmarx AI Supply Chain Security does not replace identity management, runtime agent monitoring, or human-approval systems. It complements those controls by helping organizations understand and govern the AI assets embedded in the software they build.

Discover the AI assets behind agentic applications

Govern AI agents and components across the software supply chain

Identify AI agents, models, MCP servers, frameworks, datasets, and prompts in code and configuration, then manage their risk through existing AppSec policies and workflows.

Explore the Solution

Pre-title: Discover the AI assets behind agentic applications

Title: Govern AI agents and components across the software supply chain

Body: Identify AI agents, models, MCP servers, frameworks, datasets, and prompts in code and configuration, then manage their risk through existing AppSec policies and workflows.

CTA: Explore AI Supply Chain Security