Notifications
Clear all
Topic starter
05/07/2026 6:57 pm
TL;DR: Agentic AI red teaming must move from single-turn prompts to multi-turn, stateful testing because agents can chain tools, retain memory, and trigger production actions, according to TROJ.AI. Existing IAM assumptions break when delegated authority, tool misuse, and memory manipulation can cascade across an entire workflow.
NHIMG editorial — based on content published by TROJ.AI: Agentic AI red teaming strategies for securing autonomous AI
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
Questions worth separating out
Q: How should security teams red team agentic AI workflows?
A: Security teams should test complete agent journeys, not isolated prompts.
Q: Why do agentic systems create different identity risks from chatbots?
A: Agentic systems can act, sequence tasks, and reuse state.
Q: What breaks when AI agents are given broad delegated access?
A: Broad delegated access breaks the assumption that the actor’s privilege remains narrow and predictable throughout execution.
Practitioner guidance
- Red-team full agent workflows Test multi-turn paths that include tool use, memory reuse, follow-on decisions, and recovery behaviour after an initial benign request.
- Scope delegated rights to a single task window Grant only the minimum access needed for one explicit job, then revoke it when the workflow ends.
- Validate tools before the agent can chain them Require provenance checks, structured interfaces, and behaviour validation for every tool an agent may call.
What's in the full article
TROJ.AI's full blog covers the operational detail this post intentionally leaves for the source:
- The webinar discussion on multi-turn agent red teaming and how scenario depth changes the test design.
- The specific mitigation patterns TROJ.AI associates with tool poisoning, memory manipulation, and over-permissive delegation.
- The practical framing for checker agents, structured inputs, and logging requirements in production workflows.
- The vendor’s breakdown of how to integrate red teaming earlier in the agent development cycle.
👉 Read TROJ.AI's analysis of agentic AI red teaming and runtime risk →
Agentic AI red teaming: are your identity controls keeping up?
Explore further
05/07/2026 7:20 pm
Agentic AI red teaming is now an identity governance problem, not just a model safety exercise. The article shows that the meaningful risk is not one bad prompt but a sequence of decisions, tool calls, and state reuse that can alter outcomes over time. That shifts the control question from “Is the model safe?” to “Is the delegated identity constrained enough to survive multi-step execution?” Practitioners should treat red teaming as a governance test for runtime authority.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), 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 can teams measure whether agent governance is working?
A: Teams should measure whether they can observe, constrain, and revoke agent actions at the same granularity as the task itself. Useful signals include whether tool use is logged, whether access is time-bounded, and whether the agent can be prevented from reusing stale context or expanding scope mid-session.
👉 Read our full editorial: Agentic AI red teaming exposes gaps in identity governance
