Notifications
Clear all
Topic starter
02/08/2026 11:58 am
TL;DR: Enterprise agentic systems are already exposing new attack surfaces, with only 12% of organisations having implemented guardrails and 91% lacking continuous red-teaming, according to Straiker. The security problem is no longer adoption itself but governing autonomous decisions, tool use, and cross-system actions before they become production risk.
NHIMG editorial — based on content published by Straikerai: The ABCs of Securing Agentic AI: Protecting Agents, Browsers, and Co-Pilots
By the numbers:
- only 12% of organizations have implemented agentic security guardrails
- 91% haven't red-teamed their agents on a continuous basis
- 80% of organisations report their AI agents have already performed actions beyond their intended scope
Questions worth separating out
Q: What breaks when AI agents are given broad enterprise access without tight governance?
A: Broad access turns AI agents into high-speed execution paths that can move data, spend money, modify records, or delete assets before operators can intervene.
Q: Why do agentic browsers and co-pilots complicate identity governance?
A: They complicate governance because they blur the line between user intent, system context, and delegated authority.
Q: What do teams get wrong about AI guardrails and identity controls?
A: They often assume a content filter is a substitute for access governance.
Practitioner guidance
- Inventory every agentic system and its delegated access Create a register of autonomous agents, agentic browsers, and co-pilots, then document each system's tool access, connected data sources, session scope, and human approval points.
- Apply task-scoped privileges to AI systems Replace broad inherited permissions with task-scoped access for each workflow, and require revocation after the action completes.
- Test agent behaviour under adversarial inputs Run red-team exercises against prompt injection, context poisoning, tool misuse, and destructive workflow chaining.
What's in the full article
Straiker's full blog post covers the operational detail this post intentionally leaves for the source:
- Inventory guidance for agents, browsers, and co-pilots across enterprise workflows
- Practical guardrail examples for runtime protection and behavioural monitoring
- Use-case breakdowns showing how agentic systems fail in procurement, browsing, and development workflows
- The vendor's own framing of autonomous threat assessment and deployment priorities
👉 Read Straikerai's analysis of securing agents, browsers, and co-pilots →
Agentic AI guardrails are lagging, so what should security teams do now?
Explore further
02/08/2026 1:05 pm
Agentic AI creates governance debt faster than most security programmes can absorb. The article's core point is not simply that agents are risky, but that they change the unit of control from application events to autonomous decisions. That means policy, review, and monitoring models built for deterministic software lag behind the actual operating model. Practitioners should treat agent governance as an identity and access problem first, and an AI problem second.
A question worth separating out:
Q: Which control should teams prioritise before scaling agentic AI deployments?
A: Prioritise access scoping and runtime revocation before expanding deployment. If an agent can reach too many systems or keep privileges longer than the task requires, the organisation creates a standing control gap that red-teaming alone will not solve. Access design, session limits, and revocation are the minimum controls that make the rest of the programme defensible.
👉 Read our full editorial: Agentic AI guardrails lag as autonomous agents expand the attack surface
