Notifications
Clear all
Topic starter
09/06/2026 11:08 pm
TL;DR: Lasso’s expanded automated AI red teaming adds cloud agent discovery across AWS and Google Vertex, OWASP Agentic Top 10 mapping, and one-click runtime policy generation, with scans that can run in as little as 15 to 20 minutes after change, according to Lasso Security. The deeper implication is that agent security is becoming a continuous identity and policy loop, not a one-time model test.
NHIMG editorial — what this means for NHI practitioners
By the numbers:
- The platform can rerun targeted scans in 15-20 minutes after a change, according to Lasso Security.
Questions worth separating out
Q: How should security teams govern AI agents that can call tools and reach cloud data?
A: Security teams should govern AI agents as dynamic identity subjects, not static applications.
Q: When does AI red teaming need to move from periodic testing to continuous testing?
A: Continuous testing becomes necessary when model updates, new integrations, or prompt changes can alter agent behaviour without a code rewrite.
Q: What do security teams get wrong about agentic AI red teaming?
A: The common mistake is treating prompt filters as the main control and assuming a clean single-turn result means the system is safe.
Practitioner guidance
- Inventory agent identities and tool reach Map every AI agent, cloud integration, memory store, API connection, and retrieval path before red teaming begins.
- Test multi-turn behaviour, not just prompt filters Run adversarial sequences that include context poisoning, instruction override, and tool chaining.
- Tie every finding to a runtime guardrail Require each validated issue to produce a concrete policy update, classifier rule, or tool restriction before the next deployment.
What's in the full announcement
Lasso Security's full research covers the operational detail this post intentionally leaves for the source:
- The scan workflow details for recon, static attacks, multi-turn attacks, and bespoke attack modes.
- The specific 300K-plus payload library and how the weekly variant updates are applied.
- The step-by-step path from finding to recommended guardrail and runtime policy generation.
- The timing model for pre-production scans versus change-triggered rescans after deployment.
👉 Read Lasso Security's expanded automated AI red teaming update →
AI red teaming to runtime policy: what changes for IAM teams?
Explore further
10/06/2026 1:22 am
Agentic red teaming is becoming a governance function, not a specialist test. Once an AI system can discover tools, retain context, and trigger runtime policy changes, the control problem extends beyond model evaluation. The post-test output is no longer just a finding, it is a change in the effective identity boundary. Practitioners should treat red teaming, policy generation, and access governance as one operating model.
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, inappropriately sharing sensitive data, and revealing access credentials, 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 runtime guardrails differ from red team findings in AI governance?
A: Red team findings identify the weakness, but runtime guardrails are the control that prevents it from recurring. In practice, the finding should translate into policy logic, tool restrictions, or classifier updates that change the agent’s allowed behaviour. Without that enforcement step, the test is informative but not corrective.
👉 Read our full editorial: Automated AI red teaming now reaches runtime guardrails
