Topic starter
01/08/2026 9:00 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Onyx: “Tales from the Runtime Layer: Why Authorized Agents Break Your Security and Your Infrastructure”.
Key questions
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.
Q: Why do runtime agent controls matter more than RBAC for coding agents?
A: RBAC can confirm that an agent may read code or modify files, but it cannot tell whether the specific action is safe.
Q: What are the signs that a workstation AI agent has been steered into unsafe behavior?
A: Common warning signs include a trusted process executing unexpected shell commands, legitimate developer credentials making unusual cloud calls, files or code changing in ways that do not match the user’s intent, and security tools each seeing only fragments of the chain.
Practitioner guidance
- Instrument the action boundary Inspect tool calls before execution so payload, destination, and destructive effect are visible in one control point.
- Classify high-risk tool calls Treat delete, recreate, outbound webhook, and bulk file-write actions as governed events when agents touch secrets or critical files.
- Separate read intent from send intent Require policy logic that distinguishes secret reading for remediation from secret packaging into outbound requests.
Bottom line: Authorized AI agents can still create security incidents when runtime behaviour is not evaluated before execution.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
01/08/2026 9:06 pm
Runtime intent is becoming the decisive identity signal for AI agents: authorised access no longer tells you whether an agent is acting safely. The article's core lesson is that a coding agent can be fully permitted and still be operationally unsafe if its tool call is harmful. The practitioner conclusion is that identity governance for agents must move from entitlement review to action validation.
A few things that frame the scale:
- 30.9% of organisations store long-term credentials directly in code, according to the Ultimate Guide to NHIs.
- 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: How should security teams govern AI agents that can change actions at runtime?
A: Security teams should govern runtime AI by correlating identity, data, and intent before trusting an action path. If the system can select tools or alter its sequence mid-session, a static access policy is not enough. The control objective becomes contextual verification of what the agent is doing, why it is doing it, and whether the data touched matches the approved purpose.
👉 Read our full editorial: Runtime action boundaries are becoming the new AI agent control point