Notifications
Clear all
Topic starter
22/07/2026 4:35 pm
TL;DR: Coding agent attacks can stay entirely within authorized boundaries while still exfiltrating data or changing goals, and Zenity’s research says 47% of organisations have already experienced an AI agent security incident. Permission controls alone cannot prove appropriateness, which makes intent observability and least agency the missing layer.
NHIMG editorial — based on content published by Zenity: The Permission Boundary Myth, Why Authorized Doesn't Mean Appropriate for Coding Agents
By the numbers:
- 47% of organizations have already experienced an AI agent security incident, and most didn't see it in their existing tooling.
- prompt injection ranked as the #1 concern at 29%, ahead of secrets exposure at 24% and data exfiltration at 20%.
- 80-90% of operations AI-executed.
Questions worth separating out
Q: How should security teams govern coding agents that already have access to production tools?
A: They should govern the agent as a delegated identity, not as a piece of software.
Q: Why do coding agents make least privilege insufficient on its own?
A: Least privilege limits what an identity can reach, but it does not constrain how a coding agent chains legitimate actions into an unsafe outcome.
Q: What do security teams get wrong about prompt engineering for AI agents?
A: They often assume better wording is enough to create reliable control.
Practitioner guidance
- Define least agency boundaries Write down which autonomous actions a coding agent may initiate, in what sequence, and under what oversight conditions.
- Instrument intent observability Capture task state, tool call order, and goal drift so analysts can compare what the agent was supposed to do with what it actually tried to do during the session.
- Restrict untrusted context sources Limit the content sources a coding agent can ingest during high-risk tasks, especially sources that can carry hidden instructions or manipulated payloads.
What's in the full article
Zenity's full article covers the operational detail this post intentionally leaves for the source:
- The specific detection logic behind execution observability and intent observability for coding agents
- Zenity Labs research context on prompt injection, least privilege, and least agency in agentic workflows
- Practical examples of how authorised actions become inappropriate through context manipulation
- The article's full framing for SOC 2 and EU AI Act audit expectations around automated systems
👉 Read Zenity's analysis of why authorized doesn't mean appropriate for coding agents →
Coding agents and permission boundaries: where the control gap is?
Explore further
22/07/2026 4:40 pm
Authorization is not an adequate control boundary for agentic systems. Coding agents can remain fully within permission scope and still become unsafe because the harmful behaviour sits in the sequence, not the entitlement. That means IAM alone can certify access but cannot certify appropriateness. Practitioners should treat this as a broken governance premise, not a tuning issue.
A few things that frame the scale:
- 47% of organizations have already experienced an AI agent security incident, and most didn't see it in their existing tooling, according to The State of Non-Human Identity Security.
- Our research also found that only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, which helps explain why agentic controls are lagging operational reality.
A question worth separating out:
Q: What is the difference between execution observability and intent observability for agents?
A: Execution observability shows what tools were called, what files were read, and what network requests were made. Intent observability adds the missing layer by tracking whether that sequence still matches the declared task and whether the agent’s goal has drifted. For coding agents, both are needed for credible governance.
👉 Read our full editorial: Authorized does not mean appropriate for coding agents
