AIDR vs. AI-SPM vs. Guardrails: What Each One Actually Does

Invariant Labs demonstrated in May 2025 that if a single problem is left in a public GitHub repository, it could lead a coding agent to access the private repositories of its owner and share them in a public pull request. No server-side bug to deal with in the MCP server. There were three different types of controls that could have intervened at three different points, and most teams looking for AI security these days can't say how much of each they purchased. It is this gap that is really being addressed by AIDR vs. AI-SPM vs. guardrails. The terms are used interchangeably and loosely by vendors, leaving buyers with a misconception about coverage. This article distinguishes the three by answering the question they answer and when they act, covers the attacks each one deals with that the others aren't, and finishes with the questions you need to ask any vendor before you sign on.

Three Terms, Three Different Questions

Each is a category that addresses a question the other two don't, and each asks this question at a different stage of an agent's life. Cling to the question, and most positioning for vendors becomes clear.

• AI-SPM asks: What kinds of AI are we running, what can they accomplish, and is it set up safely? It queries before deployment and always queries when agents, tools, credentials, and model versions are modified.

• Guardrails ask: Is it okay for this particular prompt, response, or tool call at this time? They respond in-line, by event, before the event is finished.

• AIDR asks: What is amiss in the behavior being observed, and what would you do about it? It is always monitoring and responds to the pattern of messages, not just one.

That's the difference between runtime, posture, and enforcement, or between, in control parlance, detective, preventive, and responsive controls. AI-SPM is a PREVENTIVE control for configuration. Guardrails are used for individual actions and are a preventive control. The first two respondents are seldom succeeded by AIDR as the detective and responsive control. They're not competing; they're complementary, and it is the useful work that has to be done to understand the seams between them.

What is AIDR?

AIDR monitors traffic from AI agents, LLM applications, and MCP traffic while they execute, creates a baseline of the traffic, and notifies or takes action when traffic is out of the norm or matches a known attack pattern. What matters is that AIDR is detection and response against AI systems, not a SOC tool that happens to leverage machine learning; CyberDefenders says that CrowdStrike, Field Effect, Zenity, and Pangea all use the term that way. For components, lifecycle, and metrics, read this comprehensive introduction to AI detection and response (AIDR).

What Is AI-SPM?

AI-SPM continuously identifies models, agents, MCP servers, and data pipelines, and evaluates how they are configured, who owns them, the identity they are running under, and the tools and data they can interact with. As cited by Concentric, Gartner views the category as software that maps infrastructure for the presence of deployed models, assistants, and agents, along with their data pipelines. The full breakdown is in this guide to AI security posture management.

What are Guardrails?

Guardrails are policy evaluations in the request path that are used to evaluate each prompt, model response, or tool call, and then either allow, block, or redact it. While a model's safety training is probabilistic and set by the provider, guardrails are set by your organization and are deterministic and auditable. This article on LLM guardrails discusses their types and deployment patterns.

Side-by-Side Comparison

The three have different priorities on nearly all axes, such as when they're paged and which team. Those differences can be found in the table below.

Comparison Table

The one thing that most people get wrong is the pre-deployment vs continuous vs real-time row. AI-SPM is not just a pre-launch activity; it needs to be maintained after launch as agents add tools and credentials. AIDR is not all real-time either; many of its benefits lie in the ability to correlate events over a few minutes or hours.

AIDR vs AI-SPM is about objects and about time: AI-SPM is about configuration, AIDR is about behavior. AI-SPM differs from guardrails in scope: posture dictates the general scope of what an agent can do, whereas a guardrail dictates whether a specific action passes through or not. When choosing between AIDR vs AI-SPM, it's hard to go wrong; the order is probably AIDR first before AI-SPM, as having a behavioural baseline without an agent that you've never interacted with is no use, and AIDR follows once this agent is up and running and is dealing with input you don't control.

Where Each One Catches What the Others Miss

By feeding in a concrete scenario into all three layers, it becomes clear where each layer catches what the others miss. For each of the situations below, one of the layers is a right control, whereas the other two are structurally blind to the problem, not just less capable of solving it.

An Over-Permissioned Agent (AI-SPM's job)

OWASP's LLM06:2025 Excessive Agency entry explains the pattern very well: an extension that reads data has access to UPDATE, INSERT, and DELETE privileges in a database. According to OWASP, there are three roots of excess agency: too much functionality, too many permissions, and too much autonomy.

The GitHub MCP incident is the same kind of failure that occurred in a developer tool. Typically, setup guides give the MCP server one big personal access token, giving read and write access to all their repositories, public and private. According to one rendition of the attack, three things were required: Untrusted content that the agent could read, private data that the agent could access, and a write tool that could exfiltrate it.

Here is what a useful posture finding for that agent looks like:

Illustrative AI-SPM finding
asset: repo-triage-agent
mcp_server: github
credential: personal access token, scope=repo (all repositories, read/write)
reads_untrusted_input: true     # issues on public repos
reaches_private_data: true      # private repos via the same token
has_write_path: true            # can open pull requests on public repos
risk: toxic combination (untrusted input + private data + write tool)

Illustrative AI-SPM finding
asset: repo-triage-agent
mcp_server: github
credential: personal access token, scope=repo (all repositories, read/write)
reads_untrusted_input: true     # issues on public repos
reaches_private_data: true      # private repos via the same token
has_write_path: true            # can open pull requests on public repos
risk: toxic combination (untrusted input + private data + write tool)

Illustrative AI-SPM finding
asset: repo-triage-agent
mcp_server: github
credential: personal access token, scope=repo (all repositories, read/write)
reads_untrusted_input: true     # issues on public repos
reaches_private_data: true      # private repos via the same token
has_write_path: true            # can open pull requests on public repos
risk: toxic combination (untrusted input + private data + write tool)

Remediation: fine-grained token scoped to the target repo; drop unused write tools

This can't be created by either of the other two layers. Any call made by the agent is structurally valid, so there is no need for a guardrail to be able to reject any individual tool call. There is no anomaly that AIDR has to highlight until the day when the permission is misused, and then you are reacting rather than preventing. Over-permission is a simple truth which can be known before an attacker arrives; and that's exactly what posture management is all about.

A Live Prompt Injection Attempt (AIDR's job)

In June 2025, Aim Security reported on a June 2025 vulnerability that allowed them to create a single malicious email to exfiltrate data from Microsoft 365 Copilot using zero-click attacks (CVE-2025-32711, CVSS 9.3). For some time, the hidden instructions were lying dormant in the user's mailbox until he asked Copilot a simple question, which was then retrieved and placed in context. The researchers were able to bypass each of Microsoft's XPIA prompt injection classifiers, slip past link redaction using reference-style Markdown, and abuse a Microsoft Teams proxy that the content security policy allowed. Microsoft fixed it on the server side and didn't report any actual exploitation.

Examine the positions of each layer. Copilot was set as it was supposed to be; there was no posture finding to raise about. There was an in-line classifier (guardrail), and a specific way of phrasing it was used to bypass it. All that could be seen was behavior: one of the assistants answering a simple question and bringing up irrelevant sensitive data, but adding a response indicating a link to external data, which contains code.

This is the starkest example of AIDR vs. guardrails. A guardrail is a judge that decides from one input or one output only. AIDR relates the input to what the agent did, what data the agent interacted with, and where the output attempted to go. For instance, Zenity claims to detect behaviour and intent “specifically” to ensure that paraphrased injections and multi-step attacks are identified despite the fact that each step may not appear malicious. The response side is as important as the detection - blocking the outbound action, ending the session, and finally keeping the full trace so that the team can see which document had the payload.

A Disallowed Output Pattern (Guardrails' job)

A support agent is allowed to have access to read customer records, since they are responsible for answering account questions. A customer finds out what is on file, and the draft response contains a complete credit card number, or a tool result has an access key in a notes field. Nothing adversarial happened.

No issue here for AI-SPM as it is legitimate access. AIDR captures normal behavior, as a basic action for this agent is reading a customer record. Only a control where the leak is detected before it is sent is placed to block the leak:

Illustrative output guardrail policy
policy: support-agent-output
applies_to: [model_responses, tool_results]
rules:
detect: [payment_card, us_ssn, cloud_access_key, private_key_block]
action: redact
detect: markdown_image_or_link
condition: domain not in allowlist
action: block
on_violation: emit_event    # becomes a signal for detection

Illustrative output guardrail policy
policy: support-agent-output
applies_to: [model_responses, tool_results]
rules:
detect: [payment_card, us_ssn, cloud_access_key, private_key_block]
action: redact
detect: markdown_image_or_link
condition: domain not in allowlist
action: block
on_violation: emit_event    # becomes a signal for detection

Illustrative output guardrail policy
policy: support-agent-output
applies_to: [model_responses, tool_results]
rules:
detect: [payment_card, us_ssn, cloud_access_key, private_key_block]
action: redact
detect: markdown_image_or_link
condition: domain not in allowlist
action: block
on_violation: emit_event    # becomes a signal for detection

The second rule is one that does the last thing on an EchoLeak-style chain, which is for the client to fetch an external URL. Guardrail vendors are now increasingly preferring deterministic checks on any representation that is precisely defined, such as card numbers and key formats, over those based on models that rely on meaning. Deterministic rules are quick, easy to explain to auditors, and do not drift.

Why Vendors Blur These Terms Together

However, it isn't all the buyer's fault. These categories are being defined by the vendors themselves in an overlapping manner.

CrowdStrike defines AIDR as a category of discovery, governance, and securing of AI systems, combining inventory and governance into a discovery and response label. By most definitions, posture work is the first step of Wiz's explanation of AIDR, with an AI bill of materials in continuous discovery. AI-SPM is one of the basic features of Zenity's AIDR product, as listed in the CyberSecTools catalogue. CrowdStrike AIDR is also available as a guardrail profile within the Bifrost AI gateway, which uses detection inline on gateway traffic. One brand and three layers.

Some of that convergence is valid. The inline sensor that enforces a guardrail also generates the telemetry AIDR requires, and posture context makes detections much more useful; Wiz makes the argument that when it comes to identifying the real blast radius of an alert, it's by correlating an agent with its non-human identity, IAM permissions, and accessible datastores. A single inventory and a single policy model on all three layers is a reasonable design.

The issue is that it appears there is no boundary between layers, and it is unclear which vendor is claiming which. A prompt filter, now called AIDR, leaves you with no sequence detection. AI-SPM does not read tool permissions and is an inventory of Bedrock endpoints, missing the over-permissioned agent altogether. On the detection side, the vendor can have excellent AI-based detection but not include any AI-specific threats. The acronyms get their credibility from EDR and XDR, but the definitions for the categories are still emerging, and there is a gap between what we label and what we can do.

How the Three Work as One Layered Stack

Order is of importance in a defense-in-depth design. The AI security stack layers reduce the load on each subsequent layer, and each assumes that the one prior to it fails from time to time.

AI-SPM Shrinks the Attack Surface Before Deployment

Posture management determines what exists and how much it is narrowed down. That includes inventory, both for in-house agents and the AI tools that employees use on their own machines, least-privilege credentials to prevent OWASP's over-ambitious agent guidance from being promoted, and adversarial testing in CI/CD to ensure that the agent that flubs an injection test doesn't get promoted. It also implies the need to be aware of the drift since launch: a new MCP server connected, a tool permission widened, a model version swapped.

This layer is to deal with the most common failure, not the most dramatic. In fact, Vectra cites Gartner, which forecasts that by 2026, at least 80% of the unauthorized use of AI will be due to internal policy violations, not malicious attacks. Posture work also generates the input for the next layer: If the triage agent never has to delete anything, then the fact is a guardrail rule.

Guardrails Enforce Policy at the Point of Action

Guardrails are placed only in two locations: at the model boundary, when evaluating prompts and responses, and at the tool-execution boundary, when checking a tool argument prior to calling the tool, and a tool result after it returns. For agents, the second placement is much more important since the bad thing is usually not a sentence, but an action.

There are three design decisions that affect the durability of guardrails in production. Firstly, deterministic and model-based checks as described above. Second, failure mode: If the guardrail service is slow or fails, does traffic fail open or fail closed, and is that failure mode per agent? Third, high-impact actions: OWASP states that high-impact actions are at the root cause of excessive agency, and that human approval gates should be used as such. Each guardrail decision (allowed or blocked) should also be sent as an event; as there should be an increase in blocked calls from one agent, a call to the guard is a detection signal.

AIDR Catches and Responds to Everything That Still Gets Through

Guardrails are neglected, and research on this is site-specific. At the 2025 ACL workshop on LLM security, Hackett and colleagues conducted experiments with adversarial ML evasion attacks and character injection attacks on six prompt injection and prompt breaking detectors, including Azure Prompt Shield and Meta Prompt Guard. Some of the techniques used for evasion, like emoji smuggling, zero-width characters, or homoglyphs, achieved up to 100% evasion in some instances without being intelligible to the underlying model, and none of the guardrails achieved a consistent success rate over all the techniques.

AIDR is based on that premise. Rather than inquiring if a message is malicious, it monitors for effects, such as an agent accessing a data source it has never been used before, calling tools at an unusual frequency, looping, or doing mutating actions out of scope. If a detection is confirmed, the response must be fast enough to matter when an agent is moving.

When each of the confirmed incidents generates an upstream change, the loop is complete. The shot that did indeed get through is a fresh guardrail rule, and the permission that caused it to be damaging is a posture finding. If it wasn't for that feedback, the three layers are only three dashboards.

How These Fit Into a Broader AI Control Plane

An AI control plane is the governance layer that connects, identifies, and enforces policies, and provides observability, allowing for a single controlled path for prompts, responses, and tool calls between every AI agent and every system it can access. The control plane is what transforms a layered AI security stack into one; AI-SPM, guardrails, and AIDR are all within that plane, not alternatives to it. The practical benefit is shared context: A posture finding can be a runtime policy without a ticket, and a detection has already learned what it was allowed to do. As stated by Obot, Forrester's principle is that this governance layer should be separated from the build and orchestration planes; that way, it can enforce policy without considering the build structure agents are working on.

What This Means When Evaluating Vendors

No red flag for a vendor that provides services on all three layers. A vendor that fails to demonstrate to you where one layer stops and the next one starts is a red flag.

Questions to Ask When a Vendor Claims to Do "All Three"

• Prove to me the posture finding for an agent with a credential that he has been granted write access for, which he never uses. If the product just inventories the endpoints, then this will not show up.

• Where does enforcement fit in? Analyze logs inline, at the LLM gateway, endpoint, or after the fact (out-of-band)? Out-of-band is detection, not a guardrail.

• What happens if your guardrail classifier is evaded? Request a sample with character-injected payloads. The answer is, "the guardrail catches it"; there is no independent detection layer.

• Is detection per request or session? AIDR is not just a prompt filter, but it has the ability to detect sequences.

• What can be done after the alert (what's the "how" part of the question)? The timeframe for blocking, redaction, end of session, or approval.

• What is fail-open or fail-closed behavior, and the added latency for every tool call?

• Are posture findings/incidents automatically changing runtime policy, or is there someone copying between consoles?

Red Flags: Coverage Claims Without a Clear Boundary Between Layers

• 1 engine, 1 data source listed by three product names.

• "AIDR" (only scan prompts, no insight into tool calls, what the agent did next).

• No access to agent tool permissions, MCP servers or employee-installed AI tools in "AI-SPM" (only cloud services).

• Denies that it blocks any prompt injection. No evasion research has been published that supports that claim for any classifier.

• Lacks a documented failure mode, latency budget, or an audit trail for decisions related to guardrails.

• There is no means to go from a detection back to the configuration that enabled it.

How Akto Covers All Three Layers

Akto is an AI agent security platform that revolves around a single inventory of agents, MCP servers, and tools, and posture, runtime guardrails, and detection follow from that shared context. Akto Atlas is for AI on employee devices, while Akto Argus is for homegrown agents and applications.

Posture Management: Discovery and Configuration Review

With over 80 connectors, Akto discovers and catalogs MCP servers, AI agents, and tools across infrastructure, cloud, and employee laptops and automatically applies an agentic security posture management to what Akto has discovered. The over-permissioned agent issue caught at the configuration layer is detected and alerted as a misconfiguration policy in the Claude environments, before it becomes an incident. The automated red teaming conducts 1,000+ probes against discovered agents and MCP servers, and agent behaviour is checked in CI/CD before deployment.

Guardrails: Runtime Enforcement at the Tool-Call Level

Akto's MCP Proxy is located in the execution path between MCP clients and MCP servers, intercepting all the requests and checking all the responses, and does not require any changes in the logic of the agents or clients. Prompt Injection, Command Injection, and SQL Injection checks are performed on requests prior to their execution; PII and sensitive data checks are performed on responses and returned as is, redacted, or blocked. This is the output scenario that is not allowed, which is dealt with inline. Also, how an agent can act, what tools and MCP servers it is allowed to invoke, and what topics and outputs are restricted, are defined through policies scoped per agent by the Argus guardrails. Wherever workflows must be moved, approvals that expire automatically and are recorded can be given with human-in-the-loop.

AIDR: Behavioral Detection and Automated Response

Through monitoring agent execution, Argus identifies and prevents attempts to inject prompts and override instructions, data transfer sensitivity, execution of unsafe tools, and attempts by the agent to engage in malicious MCP interactions. Continuous monitoring provides behavioral detection to prevent agent loops, unauthorized calls to tools, and overuse. This is the layer that is set for the live injection setting where a guardrail has already been crossed, and there is only one last signal to be used, namely the agent's own.

Final Thoughts on AIDR vs. AI-SPM vs. Guardrails

The choice between AIDR and AI-SPM is not either/or. It is an either/or choice between AIDR and AI-SPM is not the case. For each tool you own, map it to a question that it answers, then test it against an over-permissioned agent, a live injection that fails to be classified, as well as a sensitive value in a response that is not otherwise sensitive. If there is no named control for the case, the case is a gap.

These three cases are included in Akto's inventory. Before deployment, agent over-scoping, MCP servers, and permission drift emerge as agentic discovery and posture management. The MCP Proxy/Argus guardrails apply policy to all tool calls and strip or mask sensitive responses in-line. Argus runtime detection actively monitors the behavior of the agents to prevent injections, problematic tool use, and data leakage that bypass the first two layers.

To see all three layers working against your own agents, book a Agentic Security demo.

FAQs on AIDR vs. AI-SPM vs. Guardrails

Do I need all three, or does one replace the others?

None of the three supplants the other; each is unaware of the class of problems the other can solve. When forced to choose a sequence, start with Discovery and then posture your highest-risk agents, as you may not have baseline behavior or guardrail policy for any agents you have not discovered. Add detection to the tool calls that can alter data or state, then add guardrails to those tool calls when they're dealing with untrusted data at volume.

Can AI-SPM detect an active prompt injection attack?

No, AI-SPM does not have a sensor on real traffic. What it can do is mitigate the damage an injection can inflict by identifying agents that mix untrusted input with private data and a write path, and perform injection probes before deployment, revealing which ones are vulnerable. To detect an attack as it is occurring requires runtime detection.

Who typically owns each of these three functions within an organization?

Usually, posture is co-located with AppSec or the team behind the AI platform, as changes require changing credentials, tool manifests, and deployment pipelines. The guardrails are divided – security is responsible for the policy; platform/Application engineers operate the proxy/gateway and are responsible for its latency. AIDR should be part of the SOC and detection engineering, where they are already handling triage and incident response. The failure to avoid is a finding that belongs to nobody, each confirmed failure should be assigned one person to fix the runtime and one person to take the upstream posture change.