TL;DR: Authorized coding agents can exfiltrate secrets or damage infrastructure while operating within legitimate permissions, and Onyx’s runtime-layer examples show why DLP and RBAC miss intent at the action boundary. The real governance gap is assuming access safety can be judged from privilege alone when the agent’s runtime decisions are the risk.
NHIMG editorial — based on content published by Onyx: Tales from the Runtime Layer, why authorized agents break your security and your infrastructure
By the numbers:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
Questions worth separating out
Q: How should security teams control AI agents that can read secrets and modify code?
A: They should control the action boundary, not just the credential boundary.
Q: Why do RBAC and DLP often miss AI agent risk?
A: RBAC answers who may access a resource, and DLP looks for known content patterns after or during movement.
Q: What breaks when AI agents are given broad inherited permissions?
A: Broad inherited permissions break the assumption that access is tied to a narrow business need.
Practitioner guidance
- Implement action-boundary policy checks Inspect every agent tool call before execution and block actions that move from read-only inspection into external transfer, destructive file operations, or privilege-altering changes.
- Classify destructive operations as high-risk Mark delete, recreate, overwrite, permission-reset, and outbound webhook actions as requiring explicit review whenever they affect sensitive repositories or infrastructure files.
- Separate safe secret handling from unsafe secret use Allow agents to identify and annotate secrets for rotation or remediation, but prevent them from packaging secrets into scripts, posts, tickets, or network requests without approval.
What's in the full article
Onyx's full article covers the operational detail this post intentionally leaves for the source:
- Side-by-side runtime examples showing how a coding agent can appear successful while still exfiltrating secrets or destroying a file.
- The tool-call boundary logic used to distinguish a safe edit from a dangerous delete-and-recreate action.
- The human-in-the-loop escalation flow for destructive actions on sensitive infrastructure objects.
- The specific runtime visibility points that expose payload and intent in the same execution path.
👉 Read Onyx's analysis of runtime controls for AI agent security →
AI agent runtime controls: are your access boundaries holding up?
Explore further
Runtime intent is the control plane that legacy IAM never modelled. RBAC tells you whether an agent may touch a resource, but it does not tell you whether the next action is safe. Once an authorised AI agent can read, transform, and emit data in the same session, identity governance has to measure behaviour at execution time. The practitioner conclusion is simple: permission is necessary, but it is no longer sufficient evidence of safety.
A few things that frame the scale:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
A question worth separating out:
Q: Who should approve high-risk actions taken by an AI agent?
A: A verified human should approve high-risk agent actions before execution, especially where money, sensitive data or privilege changes are involved. Approval should be coupled with liveness validation and logged context so the organisation can prove the decision was intentional and attributable.
👉 Read our full editorial: Runtime action boundaries are becoming the new AI agent control point