Legacy controls were designed around devices, users, and perimeter activity, not data-centric AI behaviour. Agentic systems can query, combine, and act on data across multiple systems without looking like traditional endpoints. That makes identity, data access, and policy enforcement the critical controls. Without them, organisations either block useful AI or allow risk to expand across the environment.
Why This Matters for Security Teams
Legacy network and endpoint controls assume a bounded device, a logged-in user, and traffic that can be classified at the perimeter. agentic ai breaks that model. An AI agent can chain tools, retrieve data from multiple systems, and take actions that look ordinary at the packet level but are risky at the workflow level. That is why identity, data access, and policy enforcement matter more than device posture alone.
Current guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point to runtime governance, not static perimeter assumptions, as the control point for autonomous systems. NHIMG research on the AI Agents: The New Attack Surface report shows why this is urgent: 80% of organisations report their AI agents have already performed actions beyond intended scope, including unauthorised system access and credential exposure.
In practice, many security teams discover the gap only after an agent has already reached data or tools that no endpoint alert ever treated as unusual.
How It Works in Practice
Agentic environments need controls that evaluate intent, context, and identity at request time. A static allow list for a laptop or service account cannot express whether a given action is safe when the same agent may be summarising email in one moment, querying a customer database in the next, and opening a ticketing system after that. That is why best practice is shifting toward workload identity, short-lived credentials, and policy-as-code.
For implementation, teams usually combine cryptographic workload identity with runtime authorisation. Standards and implementation guidance from NIST SP 800-207 Zero Trust Architecture and NIST SP 800-63 Digital Identity Guidelines support the broader principle: trust should be established per request, not inherited from network location. In agentic systems, that often means ephemeral tokens, JIT approval for sensitive tools, and policy decisions enforced by engines such as OPA or Cedar rather than firewall rules.
NHIMG coverage of the OWASP NHI Top 10 shows the same pattern in practice: when agents are granted broad, durable access, they can move from simple retrieval into tool abuse, data leakage, and privilege chaining. This is where logging alone is not enough. Security teams need decisions that can say “yes” or “no” based on the task, the target system, the sensitivity of the data, and the agent’s current scope.
These controls tend to break down in highly connected environments where agents can call legacy APIs, SaaS tools, and internal services through many indirect paths because the network layer never sees the real business action.
Common Variations and Edge Cases
Tighter runtime control often increases operational overhead, requiring organisations to balance safety against developer speed and agent usefulness. That tradeoff is real, especially when teams are still deciding which actions should be fully automated and which should require human approval.
There is no universal standard for this yet. Some organisations apply strict guardrails only to write actions, while allowing broader read access for summarisation and research. Others use risk-based tiers, where low-risk agents get narrow, persistent scopes and higher-risk agents get JIT credentials and step-up approval. Current guidance suggests this should be driven by workload sensitivity, not by whether the tool is labelled “AI.”
Two edge cases matter most. First, agents that operate inside privileged workflows, such as IT automation or code deployment, can look like trusted service accounts and bypass endpoint controls entirely. Second, environments that rely on proxy inspection or EDR for containment often miss cross-system reasoning, because the agent’s harm comes from what it combines, not from any single connection. The CSA MAESTRO agentic AI threat modeling framework and MITRE ATLAS adversarial AI threat matrix are useful for mapping those failure modes.
Security teams should treat legacy network and endpoint controls as supporting telemetry, not the primary control plane, when agents can independently choose tools, data sources, and actions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A01 | Agentic systems fail when static controls cannot govern autonomous tool use. |
| CSA MAESTRO | MT-02 | MAESTRO maps threats from autonomous agent workflows and tool chaining. |
| NIST AI RMF | GOVERN | AI RMF governance is needed when agents act beyond traditional endpoint scope. |
| OWASP Non-Human Identity Top 10 | NHI-03 | NHI credential scope and rotation are central when agents use shared secrets. |
| NIST Zero Trust (SP 800-207) | PDP | Zero Trust requires per-request decisions instead of perimeter trust. |
Replace durable secrets with short-lived, scoped credentials for each agent task.
Related resources from NHI Mgmt Group
- Why do legacy network controls fall short for data security in AI environments?
- Why do traditional IAM and DLP controls fall short for agentic AI?
- Why do legacy data loss prevention controls miss risk in agentic AI environments?
- When does just-in-time access reduce risk for agentic AI, and when does it fall short?
