Notifications
Clear all
Topic starter
09/06/2026 11:50 pm
TL;DR: Agentic AI red teaming that stays at the API endpoint misses the context pipeline, tool calls, and output sinks that shape real attack paths, according to Pillar Security. Coverage has to shift from prompt testing to runtime discovery, because the security question is no longer whether a model answers badly, but whether the agent can be driven to misuse connected systems.
NHIMG editorial — based on content published by Pillar Security: Agentic AI red teaming and the five dimensions your testing should cover
By the numbers:
- 33% of organisations report their AI agents have accessed inappropriate or sensitive data beyond their intended scope.
Questions worth separating out
Q: How should security teams red team AI agents that use tools and memory?
A: Security teams should test AI agents through the same interface and runtime path production uses, then validate the tools, memory stores, and downstream sinks those agents can reach.
Q: Why do API-level tests miss real AI agent attack paths?
A: API-level tests miss real attack paths because they bypass the context pipeline and only see the model response.
Q: What should a high-quality AI red teaming finding include?
A: A high-quality finding should include the entry point, the tool pivot, the data or system reached, and the business impact.
Practitioner guidance
- Test through the production interface, not only the API Run adversarial scenarios through the same UI, browser, or workflow path that users and attackers will actually use, so context trimming, retrieval, rendering, and tool calls are all exercised.
- Map verified tool and data dependencies before testing Build a runtime inventory of tools, MCP servers, permissions, data stores, and inter-agent links by observing side effects such as webhook calls, writes, and downstream messages.
- Require exploit-validated findings with business impact Do not accept findings that only show an unsafe prompt response.
What's in the full article
Pillar Security's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step comparisons between API-only testing and browser-based agent red teaming
- Practical examples of structured reconnaissance across tools, permissions, and data flows
- How the five red teaming dimensions map to remediation integration in live programmes
- Detailed discussion of findings quality and how to translate results into runtime guardrails
👉 Read Pillar Security's analysis of agentic AI red teaming and runtime attack paths →
Agentic AI red teaming: what the API test is missing?
Explore further
10/06/2026 2:20 am
The API is not the attack surface for agentic systems. Agentic red teaming that stops at the model endpoint is testing a different system from the one in production. The context pipeline, tool invocation layer, and output sinks are where the real attack path lives, and those layers can rewrite, redirect, or amplify the model's behaviour. Practitioners should treat API-only results as partial evidence, not program coverage.
A few things that frame the scale:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: How do organisations decide whether agentic red teaming is actually working?
A: Organisations should judge agentic red teaming by coverage of runtime paths, not by the number of prompts tested. If the programme can map verified tools, permissions, data flows, and downstream actions into reproducible exploit chains, it is working. If it only produces response-level failures, it is still testing the wrong surface.
👉 Read our full editorial: Agentic AI red teaming fails when tests stop at the API
