Machine-generated requests that may come from scripts, automations, or autonomous agents. In identity governance terms, AI traffic is not trusted because it is automated. It must be classified by authority, purpose, and scope before it is allowed to perform sensitive actions.
Expanded Definition
AI traffic is machine-generated request activity that may originate from scripts, scheduled automations, integrations, or autonomous agents with tool access. In NHI security, the key distinction is not whether the request is “legitimate” in a business sense, but whether it has been classified by authority, purpose, and scope before it is allowed to reach sensitive systems.
This matters because AI traffic often looks operationally normal while behaving very differently from human activity. A service account issuing API calls, an agent chaining prompts into actions, and a batch job calling the same endpoint can all appear as automated traffic, yet they carry different risk profiles and privilege assumptions. Definitions vary across vendors on where AI traffic ends and broader machine-to-machine traffic begins, so organisations should avoid treating every automation as equally trusted. The NIST Cybersecurity Framework 2.0 provides a useful governance lens for identifying, protecting, and monitoring automated access paths, but it does not by itself resolve AI-specific authority questions.
The most common misapplication is treating all automated requests as low-risk internal traffic, which occurs when teams skip requester classification and allow execution authority to expand without review.
Examples and Use Cases
Implementing AI traffic controls rigorously often introduces routing and approval overhead, requiring organisations to weigh faster automation against tighter blast-radius limits.
- A customer support agent invokes a ticketing API to summarise case history, but only after its scope is limited to read-only access and its outputs are logged for review.
- A code-generation workflow opens a pull request and requests build telemetry, but it is blocked from deploying changes until an explicit approval step confirms intent and authority.
- A data-retrieval agent queries internal documents through a brokered service, with request frequency capped to reduce the chance of prompt abuse or runaway calls.
- A scheduled integration refreshes inventory data every hour, and the system distinguishes it from interactive agent traffic so anomaly detection can flag unexpected expansions in scope.
- An exposed credential is used to generate machine traffic toward cloud APIs, reinforcing why NHIMG’s LLMjacking research and the NIST Cybersecurity Framework 2.0 both matter when automation is permitted to act.
These scenarios show why AI traffic should be tagged by identity source, declared purpose, and privilege boundary rather than by infrastructure label alone. The same request path may be safe for a cron-like sync job and dangerous for an agent that can chain actions across multiple systems.
Why It Matters in NHI Security
AI traffic becomes a security issue when teams assume automation can be trusted simply because it is owned by an internal system. That assumption creates openings for secret abuse, agent misuse, and uncontrolled downstream actions. NHIMG research on The State of Secrets in AppSec shows that 43% of security professionals are already concerned about AI systems learning and reproducing sensitive information patterns from codebases, which underscores how easily automated flows can become a data exposure path.
Once AI traffic is allowed to inherit human-like privileges, it can amplify the impact of a leaked token, a misconfigured integration, or an over-permissioned service account. That is why governance should distinguish between benign automation, semi-autonomous assistance, and agentic execution authority. The operational goal is not to stop automation, but to ensure every automated request has an explicit identity, bounded purpose, and reviewed scope. Organisational risk typically becomes visible only after an agent or script has already issued unauthorized calls, at which point AI traffic classification becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | AI traffic must be classified before automated identities are trusted to act. |
| NIST CSF 2.0 | PR.AA-01 | Identity proofing and access governance apply to machine-originated requests too. |
| OWASP Agentic AI Top 10 | AGENT-03 | Agentic systems require constrained execution authority and action scoping. |
Classify automated requesters and bind each to least-privilege, purpose-limited NHI controls.
