Campus Agent Identification and Scope-Down Access Control

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

This document focuses on these capabilities in managed networks. The primary example is an enterprise campus network, but the same architectural problem also appears in home networks when multiple AI agents, smart devices, and ordinary applications share the same subscriber access and public address.

Example Campus Network Architecture

Example campus network architecture

Home Network and BNG Use Case A residential user may deploy several AI-capable systems in the same home network, including a voice assistant, a smart-home hub, a personal computer agent, a mobile-device agent, and automation components embedded in cameras, televisions, or home appliances. These agents may all share the same Wi-Fi network, home gateway, NAT state, IPv6 prefix, and subscriber access line. From the perspective of an upstream network, these agents may be difficult to distinguish because their traffic is aggregated by the home gateway and then carried over a subscriber session to the broadband network gateway (BNG). A BNG normally enforces policy at the granularity of a subscriber line, access session, IPv4 address, IPv6 prefix, or service profile. This granularity is useful for broadband access control, but it is too coarse when different home agents perform different tasks. For example, a home assistant may need to access an approved weather API and a vendor cloud for device control. A parental-control agent may need to access a limited set of policy and reputation services. A personal productivity agent may need to access calendar and email services. These agents should not automatically inherit the same Internet reachability merely because they share the same home network and subscriber line. The BNG use case is not intended to move all application authorization into the access network. Instead, it illustrates a coarse network-level scope-down boundary that can complement application-layer authorization and home-gateway controls. A home gateway or trusted agent runtime may provide an Agent-ID, task indication, or locally derived policy context to a provider or home-network enforcement function. The BNG or a provider-managed policy-enforcement point can then apply limited reachability constraints such as allowed destination classes, mandatory security gateway paths, time-bound access, or blocking of high-risk destinations for selected agent traffic.

Home network agent traffic aggregated at a BNG This use case introduces the following requirements:

the access network should not treat all traffic behind the same subscriber line as having identical agent authorization semantics;
the BNG or provider-managed enforcement point should be able to consume a minimal policy context for selected agent traffic where available;
policy should remain bounded by the subscriber's service agreement, parental-control settings, user consent, and applicable provider policy;
task-specific limits should be time bounded and revocable without changing the subscriber's basic network attachment; and
privacy-sensitive task details should not be disclosed to the provider when coarse destination or service-class constraints are sufficient.

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.
Broadband Network Gateway (BNG):: A provider network function that terminates or manages broadband subscriber sessions and can apply subscriber-level policy. In this document, a BNG is considered an example of an in-path network device for the home-network use case.

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. Residential access networks introduce a related form of aggregation. A home gateway and BNG may see a subscriber line, IP address, prefix, or access session, while multiple home agents behind that subscriber attachment may have very different tasks and risk profiles. Treating the entire home network as one authorization subject can over-authorize agent traffic and can make it hard to apply task-specific controls such as child-safety policy, vendor-cloud restriction, or mandatory secure egress.

Architecture

Scope-down authorization through an in-path network device | | | | | | | | | | OAuth token | | | |<-----------| | | | resource request + Agent-ID | | |------------------------->| | | | | | | | | policy evaluation | | | | | | | | | request + scoped token | | | |------------------------->| | ]]> In the home-network use case, the Network Device may be a home gateway, a BNG, or a provider-managed enforcement point associated with the subscriber session. The same principle applies: the enforcement decision should be based on the identified agent traffic and the task-bound policy, not merely on the subscriber line or shared public address.

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. Model C: In a home-network deployment, a home gateway, BNG, or provider-managed enforcement point applies coarse reachability constraints for selected agent traffic based on a subscriber policy profile and minimal task or Agent-ID context. This model is useful when not every home device, cloud service, or legacy protocol can consume agent-aware application tokens. 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, ACL enforcement, home-gateway policy, or subscriber-session policy. BNG policy confusion: In the home-network use case, a BNG or provider-managed enforcement point MUST NOT treat all agents behind the same subscriber attachment as having the same task authorization when more specific policy context is available. Conversely, a provider network MUST NOT infer sensitive task details beyond what is required for coarse network 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. In the home-network and BNG use case, provider-visible policy context can reveal household behavior, device types, user objectives, or the presence of specific agents. Deployments SHOULD minimize the disclosure of task content to the access provider and use coarse policy classes, local home- gateway enforcement, or pairwise identifiers where possible.

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.