Notifications
Clear all
Topic starter
02/08/2026 12:11 pm
TL;DR: As enterprises embed AI agents into browsers, developer tools, SaaS platforms, and internal workflows, the risk shifts from bad prompts to manipulation across context, tools, and actions, according to Straiker. Runtime detection and enforcement now matter more than static input scanning, because agentic workflows can quietly form exploit chains.
NHIMG editorial — based on content published by Straikerai: When AI Agents Ship by Default, Security Has to Run in Production
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%).
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments.
Questions worth separating out
Q: What breaks when AI agents are managed like ordinary machine identities?
A: What breaks is the assumption that access scope can be fully understood from provisioning data and quarterly review.
Q: Why do AI agents complicate existing IAM and PAM controls?
A: AI agents complicate IAM and PAM because they often inherit delegated credentials, operate across multiple systems, and keep acting after the initial approval moment has passed.
Q: How do security teams know whether agent guardrails are working?
A: They know guardrails are working when denied tool calls are visible in logs, high-risk paths are blocked consistently, and the agent cannot override policy from inside its own session.
Practitioner guidance
- Map every agent to an explicit identity and permission boundary Inventory browser agents, coding agents, and connector-driven enterprise agents, then tie each one to a named owner, scoped privileges, and a documented approval path.
- Instrument runtime detection for instruction override attempts Detect indirect prompt injection, context poisoning, and instruction manipulation before the agent executes a tool call.
- Constrain tool access to task-scoped least privilege Separate read, write, and destructive actions across connectors, and remove broad default permissions from agent workflows.
What's in the full article
Straiker's full post covers the operational detail this analysis intentionally leaves for the source:
- Detection logic for instruction manipulation, tool misuse, resource exhaustion, and reconnaissance across live agent workflows
- Examples of how accuracy tuning reduces false positives while preserving signal quality in production
- The research loop behind improved golden datasets and coverage for browser agents, coding agents, and connector-heavy enterprise agents
👉 Read Straiker's analysis of production-grade controls for AI agent security →
AI agent execution risk: are your runtime controls keeping up?
Explore further
02/08/2026 1:14 pm
AI agents are becoming a governance surface, not just an application feature. Once agents can browse, retrieve, and act, security teams must govern their behaviour as they would any other non-human identity with delegated access. That means runtime controls, scoped tools, and auditable action paths become part of identity governance, not an add-on. Practitioners should treat agent deployment as a permissions design problem first and an AI problem second.
A question worth separating out:
Q: Who is accountable when an AI agent takes an unsafe action?
A: Accountability should sit with the business owner of the agent, the team that provisioned the access, and the control owners responsible for monitoring and revocation. If no one can answer who approved the identity, the scope, and the oversight model, the governance framework is not complete enough for production.
👉 Read our full editorial: AI agents are becoming an execution surface for production risk
