| Internet-Draft | Campus Agent Scope-Down | July 2026 |
| Shang, et al. | Expires 7 January 2027 | [Page] |
AI agents operating in enterprise campus networks execute user-delegated Tasks by invoking multiple tools and services, often without continuous user supervision. Traditional authorization models assume stable applications and human-driven interactions, creating a mismatch when applied to autonomous agents that can chain actions across heterogeneous systems.¶
Campus environments also contain heterogeneous and legacy services across diverse protocols, making per-service agent-aware authorization difficult to deploy consistently. Similar problems can also appear in residential access networks where home AI agents, smart-home hubs, and personal devices share a subscriber line and are connected through a broadband network gateway (BNG).¶
This document describes the problem space for campus agent access control and argues that agents require task-bound privilege reduction ("scope-down") and that enforcement can be provided by in-path network devices in order to preserve compatibility with existing systems. It also describes a home network and BNG use case where the access provider or home gateway can provide a coarse but useful network-level boundary for agent traffic.¶
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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is 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. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 7 January 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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 [RFC6749] and JSON Web Tokens [RFC7519] 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:¶
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.¶
+----------------------+
| Private Cloud RS |
+----------^-----------+
|
+----------------------+
| Public Cloud RS |
+----------^-----------+
|
+-----+-----+
| Gateway |
+--+------+--+
| |
| +-------------+
| |
v v
+------------------------------------+ +----------------------+
| Campus Network | | Branch Network |
| | | |
| +--------------------+ | | +-------------+ |
| | Core Switch | | | | Switch | |
| +----+----------+----+ | | +--+---------++ |
| | | | | | | |
| +-----+----+ +----+----+ | | +--+--+ +--+--+ |
| | Switch | | Switch | | | | App | |Agent| |
| +----+-----+ +----+----+ | | +--+--+ +--+--+ |
| | | | | | | |
| +--+--+ +--+--+ | | +--+--+ +--+--+ |
| | App | |Agent| | | |User | |User | |
| +--+--+ +--+--+ | | +-----+ +-----+ |
| | | | | |
| +--+--+ +--+--+ | | |
| |User | |User | | | |
| +-----+ +-----+ | | |
| | | |
| +--------------+ +-------------+ | | |
| | Resource Svr | | IdP / AS | | | |
| +--------------+ +-------------+ | | |
+------------------------------------+ +----------------------+
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 | | Smart Hub | | User Apps | |
| +---+----+ +-----+-----+ +------+-----+ |
| | | | |
| +--------------+----------------+ |
| | |
| +------+-------+ |
| | Home Gateway | |
| +------+-------+ |
+---------------------|------------------------+
|
Subscriber Session
|
+--------+--------+
| BNG |
+--------+--------+
|
Provider / Internet
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.¶
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 [RFC2119] and [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Software that performs tasks on behalf of a user or principal and may autonomously invoke services or tools.¶
A verifiable identifier associated with a specific agent instance.¶
The human user or entity on whose behalf the agent operates.¶
The OAuth authorization server issuing tokens.¶
A server hosting protected resources.¶
A network device positioned on the traffic path capable of enforcing policy decisions.¶
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.¶
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.¶
Principal Agent Network Auth Resource
| Application Device Server Server
| | | | |
| OAuth req | | | |
|--------------------------------------->| |
| | | | |
| | | 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.¶
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 [RFC8693] 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.¶
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.¶
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.¶
This document makes no requests of IANA.¶
The authors thank members of the research community for discussions on agent identity and authorization models in campus networks.¶