Campus Agent Identification and Scope-Down Access Control

Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). The list of current Internet-Drafts is available at: https://datatracker.ietf.org/drafts/current/ Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time.

Introduction Enterprise campus networks increasingly carry traffic generated by AI agents acting on behalf of users. These agents may retrieve internal documents, query knowledge bases, invoke APIs, and automate workflows across multiple services. Unlike conventional applications, agents may be instantiated per task and autonomously chain operations based on intermediate results. Permissions that are safe for human operation may therefore become unsafe when exercised by an autonomous actor operating at machine speed. Existing standards such as OAuth 2.0 and JSON Web Tokens provide identity and delegation primitives. However, these mechanisms alone do not address task-bound privilege reduction or enforcement in heterogeneous campus environments. Deployable campus agent security therefore requires two capabilities:

recognition of agent-generated traffic
enforcement of task-bound privilege scope

Example Campus Network Architecture

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in and when, and only when, they appear in all capitals, as shown here.

Agent:: Software that performs tasks on behalf of a user or principal and may autonomously invoke services or tools.
Agent Identifier (Agent-ID):: A verifiable identifier associated with a specific agent instance.
Principal:: The human user or entity on whose behalf the agent operates.
Authorization Server (AS):: The OAuth authorization server issuing tokens.
Resource Server (RS):: A server hosting protected resources.
In-Path Network Device (ND):: A network device positioned on the traffic path capable of enforcing policy decisions.

Problem Statement Traditional authorization models assume stable applications and human-driven workflows. Agents violate these assumptions by dynamically selecting targets and chaining tools across systems. Without task-bound constraints, agent-driven workflows introduce several risks:

over-broad aggregation of internal data across multiple systems
cross-boundary exfiltration when generated output is transmitted externally
unsupervised tool chaining across services without user review
machine-scale amplification of data access or operations

Campus environments also contain heterogeneous services and legacy protocols, making it operationally infeasible to require each service to implement agent-aware authorization.

Architecture | | | | | | | | | | OAuth token | | | |<-----------| | | | resource request + Agent-ID | | |------------------------->| | | | | | | | | policy evaluation | | | | | | | | | request + scoped token | | | |------------------------->| | ]]>

Deployment Models Different deployment models are possible. Model A: Network Device performs token validation and policy enforcement without issuing new tokens. Model B: Network Device obtains a reduced-scope token through OAuth Token Exchange or via Authorization Server policy decisions. This document does not define a new OAuth grant type or token format and relies on existing OAuth mechanisms.

Security Considerations Deployments must address several threats. Agent identity spoofing: Deployments MUST ensure that Agent-ID cannot be forged or reused across devices. Token replay: Deployments SHOULD bind tokens to the Network Device as audience and MAY use mutual TLS or channel binding to reduce replay risk. Network bypass: Network architectures SHOULD enforce that agent traffic cannot bypass the Network Device through fabric policies, VRF isolation, or ACL enforcement. Intent mis-modeling: Scope-down mechanisms ensure that authorization does not expand privilege beyond the original delegation but cannot eliminate risks caused by incorrect intent interpretation.

Privacy Considerations Deployments may log Agent-ID and authorization decisions for auditing. Operators SHOULD minimize collection of unnecessary personal data and avoid storing sensitive token contents. Deployments SHOULD consider using short-lived or per-task Agent-IDs and SHOULD distinguish Principal identifiers from Agent-IDs in audit logs.

IANA Considerations This document makes no requests of IANA.

Acknowledgements The authors thank members of the research community for discussions on agent identity and authorization models in campus networks.

References

Normative References