| Internet-Draft | Campus Agent Scope-Down | March 2026 |
| Shang, et al. | Expires 13 September 2026 | [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. 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.¶
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 13 September 2026.¶
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.¶
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.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors.¶
This document is subject to BCP 78 and the IETF Trust’s Legal Provisions Relating to IETF Documents.¶
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:¶
+----------------------+
| 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 | | | |
| +--------------+ +-------------+ | | |
+------------------------------------+ +----------------------+
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.¶
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.¶
Principal Agent Network Auth Resource | Application Device Server Server | | | | | | OAuth req | | | | |--------------------------------------->| | | | | | | | | | OAuth token | | | |<-----------| | | | resource request + Agent-ID | | |------------------------->| | | | | | | | | policy evaluation | | | | | | | | | request + scoped token | | | |------------------------->| |¶
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.¶
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, 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.¶
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.¶
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.¶