Security Considerations and Requirements for Intent-Based Requests in Agentic Systems

1.1. Scope

This document focuses on security considerations for intent-based requests in multi-hop agentic systems. While examples may reference telecom or networking contexts, the analysis applies broadly to any domain where intent processing spans multiple trust boundaries. It complements requirements-oriented analyses of agent security such as [I-D.ni-a2a-ai-agent-security-requirements], focusing specifically on intent origin, multi-hop directive integrity, and drift.¶

2.1. Conventions

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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document is Informational; descriptive text ("the system validates ...") is used in preference to normative keywords.¶

2.2. Definitions

This document uses the following terms:¶

Intent:

A declarative expression of desired operational goals and outcomes, without specifying how to achieve or implement them. This definition is aligned with intent-based networking (IBN) guidance [RFC9315] [RFC9316] and its use cases [I-D.irtf-nmrg-ibn-usecases].¶

Intent-Based System (IBS):

A system (or chain of systems) that receives an intent and translates, validates, and orchestrates it toward fulfillment. The term parallels intent-based system decomposition used in IBN [RFC9315] and is not specific to any deployment domain.¶

Intent Translation:

The process of transforming an intent into more concrete representations, such as constraints, objectives, candidate procedures, or executable directives.¶

Constraint:

A condition that limits acceptable outcomes or actions. Constraints may include invariants, policy rules, safety boundaries, and compliance requirements.¶

Constraint Validation:

Verifying whether an intent and/or its derived artifacts comply with applicable constraints, invariants, policy rules, and safety boundary requirements.¶

Invocation:

A request to a tool or service intended to fulfill an intent (e.g., API call, workflow step, actuation command).¶

Invocation Validation:

Determining whether an invoker holds the required privileges to invoke a tool or service and whether invocation parameters satisfy the requirements and constraints specified by the intent.¶

Observation:

Telemetry, events, measurements, or other signals used for monitoring and assurance.¶

Drift:

A divergence between the intent (including its constraints) and the realized plan or actions over time or across multi-hop transformations. In the realized trace, such a divergence may appear in two distinct shapes: (a) a constraint that is present but violated by a realized action, or (b) an expected control (e.g., an authorization or consent check) that is absent from the trace (a silent failure). These two shapes require different audit evidence and detection logic.¶

Derived Directive:

An executable or enforceable artifact generated from an intent through translation, such as an allowed rule set, capability token, or authorization grant.¶

Intent Originator:

The entity that produces an intent (e.g., a user, an application, or an agent). The originator is the asserted source of the intent and is distinct from the entity that merely transports or forwards it.¶

Admission Control:

The decision, taken before an intent is forwarded into or accepted by the processing chain, of whether to admit the intent, based on the verified origin, the originator's authorization to request the targeted service, and applicable consent.¶

Admission Assertion:

An abstract artifact by which an admission point conveys its verified origin and admission decision (and any associated security context) to downstream entities for re-verification. Its concrete encoding is out of scope for this document.¶

2.3. Acronyms

IBN:

Intent-Based Networking¶

IBS:

Intent-Based System¶

3.1. Settings and Example Architecture

This document considers two structural settings. Setting A is the origination/admission boundary, where intents enter the system from possibly many co-resident applications or agents at an entry point such as a user-facing device; this is the locus of Scenario 1 (origin, authorization, and consent) and is not inherently multi-hop. Setting B is the multi-hop processing chain, where an admitted intent is translated and propagated across multiple entities before execution; this is the locus of Scenario 2 (directive integrity and drift). The example below illustrates Setting B; an illustration of Setting A appears in Scenario 1 (Section 4.2).¶

The following example is illustrative and is based on a sequential multi-agent orchestration pattern observed in deployed frameworks. This section presents an illustrative sequential multi-agent pattern; other deployments may use parallel, handoff, group-chat, manager-worker, or tool-centric architectures. The property of interest, common to such patterns, is that intent is decomposed and propagated across entities and must remain preserved, verifiable, and contextually appropriate as it flows through the system.¶

                                          |intent input
                                          v
                                  +--------------------+
                                  |      Agent1        |
                                  | (e.g., Summarizer) |
                                  +--------------------+
                                          v
                                  +--------------------+
                                  |     Agent2         |
                                  | (e.g., Translator) |
                                  +--------------------+
                                          v
                                  +--------------------+
                                  |     Agent3         |
                                  |   (e.g., QA)       |
                                  +--------------------+
                                          |    Result
                                          v

Figure 1 illustrates one such pattern, the sequential orchestration of the Microsoft Agent Framework [MS-AF-SEQ], cited here only as a concrete example of a deployed framework. Agents process intents in a pipeline; by default, each agent receives the conversation from the previous agent, preserving context while allowing specialized processing at each stage. Characteristics relevant to the threats below include:¶

1. Agent Pipeline: agents are arranged in a predefined sequence where output from one agent becomes input for the next.¶
2. Shared Context: by default, each agent consumes the previous agent's full conversation, so context is preserved across the pipeline; the framework also allows agents to be configured to consume only the previous agent's response messages, which truncates earlier context.¶
3. Human-in-the-Loop: optional approval points for sensitive operations (e.g., tools marked as approval-required).¶
4. Mixed Executors: the ability to combine LLM-based agents with custom code executors.¶

The original intent can be preserved through the shared conversation history, with each agent adding specialized processing while maintaining contextual continuity. However, under certain threats, the intent may change, potentially introducing security risks. The next section describes these threats.¶

3.2. Threats

With reference to the illustrative pattern in Section 3.1, the following representative threats are considered. T1-T5 arise during multi-hop intent processing, while T6-T7 arise at the intent origination/admission boundary, i.e., where an intent enters the system:¶

T1 (Directive Tampering/Substitution):

A malicious or compromised intermediary agent (a node that terminates any hop-by-hop secure channel, not merely an on-path observer) modifies conversation history or derived directives between pipeline stages, altering budget constraints or action parameters while maintaining superficial coherence.¶

T2 (Unauthorized Invocation / Privilege Escalation):

An agent abuses mixed-executor capabilities by smuggling unauthorized commands through parameter injection, bypassing the intended privilege boundary because custom code executors run arbitrary code without an enforced access-control layer.¶

T3 (Constraint Bypass):

Security constraints degrade across pipeline stages due to context truncation or improper inheritance, violating the shared-context integrity assumption.¶

T4 (Multi-Hop Semantic Drift):

Gradual semantic deviation occurs as agents reinterpret ambiguous instructions across hops, causing final actions to diverge from original intent boundaries despite syntactically intact messages.¶

T5 (Monitoring Evasion / False Observations):

Attackers evade detection by suppressing, forging, or selectively presenting observations used for assurance and drift detection.¶

T6 (Origin Spoofing / Forged Provenance):

A co-resident or upstream malicious application or agent fabricates an intent artifact that appears to originate from the user or a legitimate originator, so that downstream entities accept and act on an intent that the claimed originator never authorized.¶

T7 (Unauthorized or Non-Consensual Origination):

An originator that is not entitled to request the targeted service, or that is operating in a disallowed execution context (e.g., unattended background execution), issues a high-impact intent without valid user consent; the system admits it because it does not gate on the originator's eligibility, execution context, or explicit consent.¶

NOTE1: By default, the example framework does not provide cryptographic binding between pipeline stages, so agents cannot be assumed to be mutually trustworthy. The degree of such binding may vary across implementations. In particular, T1 is a node-level threat: transport security (e.g., a hop-by-hop secure channel) protects the link between two entities but not against a malicious or compromised intermediary that terminates the channel.¶

NOTE2: Human approval may be agent-triggered rather than enforced by the receiver, creating bypass opportunities.¶

3.3. Requirements

Based on the threats above, this document identifies the following security requirements, grouped by where in the intent lifecycle they apply. The grouping distinguishes controls that act before an intent enters the system (admission-time) from those that act during multi-hop processing and at execution. Requirement numbering (R1-R9) is retained from prior revisions and is not sequential within groups.¶

Transformation and propagation requirements:¶

R1 (Provenance and Authorization Boundary Binding):

The system provides a verifiable binding between the intent, derived directives, and the applicable authorization boundary, such that unauthorized expansion can be detected or prevented.¶

R2 (Chain-of-Custody for Derived Directives):

The system protects derived directives against tampering and substitution across multi-hop propagation.¶

R3 (Constraint Validation):

The system validates the intent and/or derived artifacts against applicable constraints, invariants, policy rules, and safety boundaries before accepting or executing actions.¶

Invocation-time requirements:¶

R4 (Invocation Validation):

The system validates that an invoker holds the required privileges to invoke a tool/service and that invocation parameters satisfy intent constraints prior to and/or at invocation time.¶

R5 (Non-Bypass Enforcement):

The execution endpoint enforces constraints and authorization boundaries such that direct/side-path invocation cannot bypass required checks.¶

Assurance requirements:¶

R6 (Observability and Auditability):

The system provides sufficient observations and audit evidence to support compliance assessment, drift detection, and incident investigation. The audit evidence is able to express both shapes of divergence: a constraint present but violated, and an expected control absent from the trace. Observations benefit from a shared, interoperable schema so that audit evidence remains portable across multi-hop, multi-vendor chains rather than siloed per intermediary; emerging generative-AI observability conventions are one example of such a schema (e.g., the OpenTelemetry GenAI semantic conventions [OTEL-GENAI]). This document does not mandate or endorse a specific observation format.¶

R7 (Policy-Driven Drift Response):

Upon drift detection or constraint violation, the system supports policy-driven responses (e.g., deny, degrade, re-confirm, re-negotiate, fallback). A violated constraint and an absent expected control may map to different responses.¶

Admission-time requirements:¶

R8 (Origin Authentication):

The system provides a verifiable binding between an intent artifact and the identity of its actual originator, such that a forged or spoofed origin can be detected before the intent is admitted or forwarded.¶

R9 (Originator Authorization and Consent-Gated Admission):

Before admitting or forwarding an intent, the system determines whether the originator is permitted to request the targeted service, based on risk-relevant originator attributes and applicable permission policy. For high-impact or irreversible actions, the system additionally obtains and verifies explicit user consent. Intents from unauthorized originators, from originators in a disallowed execution context, or lacking required consent are rejected or escalated.¶

4.1. Placement of Checks

A recurring, scenario-agnostic design question is where, along the path from origination to execution, a given check is performed. This applies both to admission checks (Scenario 1) and to directive-integrity checks (Scenario 2). Three placements are possible:¶

Endpoint-only:

Only the final execution endpoint validates. This is simple, but it cannot detect tampering unless the original binding survives intact to the endpoint, it fails if a side path bypasses the endpoint's gate, and drift accumulates without early signal.¶

Earliest-point / per-hop:

The originating or each intermediary point validates. This enables early detection and local enforcement, but a malicious hop will not honestly validate itself, every hop is exposed to the intent, and each hop must understand the relevant semantics.¶

Combined (hybrid):

A property is captured or bound at the earliest point where it is verifiable, carried end-to-end so it survives relays, re-verified at trust-boundary crossings for early detection, and re-verified at the execution endpoint as the authoritative, non-bypassable gate (R5). Intermediaries are not trusted; intermediate checks are defense-in-depth rather than the sole line of defense.¶

A consequence is that integrity cannot rely on transport security alone: an intermediary that re-terminates a transport-layer secure channel (e.g., a relay or proxy) breaks transport-layer evidence, so binding is applied at the intent/directive layer such that it passes through such intermediaries opaquely.¶

In practice, the Invocation Gate, Constraint Validator, and Admission Control functions may be realized by an AI/agent gateway, a tool gateway, or an on-device admission point. Such gateways are natural policy enforcement points, but a single gateway can be bypassed by side paths (e.g., directly reachable tool servers), which is why the endpoint also enforces (R5).¶

4.2. Scenario 1: Spoofed Origin and Non-Consensual Intent Origination

Setting:

A user-facing device (e.g., a terminal) hosts multiple applications and agents. Any of them can express intents that are submitted to a local Intent Client and forwarded to a remote Intent-Based System (IBS) that accepts intent artifacts and may trigger high-impact services or actions. The remote receiver acts on whichever intents it admits.¶

Actors:

Intent Originator (the user or a legitimate originator), a legitimate local agent, a malicious co-resident application/agent, the Intent Client, and the remote IBS / Tool/Service Provider.¶

Assets:

Originator identity and account/identity bindings, user consent, the permission policy that determines which originators may request which services, billing/spending limits, and safety constraints.¶

Attack Sketch:

1. The malicious application fabricates an intent artifact that appears to originate from the user or a legitimate agent (spoofed provenance); or an originator that is not entitled to the targeted service, or is running unattended in the background, issues a high-impact intent.¶
2. The Intent Client / IBS forwards the intent, and the remote receiver executes high-impact actions (purchases, data disclosure, account or state changes) without verifying the actual originator, the originator's eligibility for the requested service, the originator's execution context, or valid user consent.¶

Impact:

Unauthorized actions, fraud, privacy leakage, billing abuse, and irreversible side effects.¶

Relevant Requirements:

R8 (Origin Authentication), R9 (Originator Authorization and Consent-Gated Admission), R3 (Constraint Validation), R6 (Observability and Auditability).¶

Figure 2 illustrates the attack: a spoofed or unauthorized origin (marked X) among co-resident applications on a user-facing device, whose intent is forwarded without origin or consent verification and is acted upon at the execution endpoint. The controls that address this attack are discussed in Section 4.2.1.¶

   +------------------------------------------+
   |  user-facing device                      |
   |                                          |
   |   [ legit app ]     [ malicious app (X) ]|
   |          \             /                 |
   |           v           v                  |
   |       +-------------------+              |
   |       |   Intent Client   |              |
   |       +---------+---------+              |
   +-----------------|------------------------+
                     |  intent forwarded with no
                     |  origin / consent verification
                     v
               [ relay / network ]
                     |
                     v
           +-----------------------+
           |  Execution Endpoint   |---> high-impact action on a
           +-----------------------+     spoofed / unauthorized intent

   (X) = spoofed or unauthorized origin

4.3. Scenario 2: Directive Tampering and Authorization Boundary Expansion

Setting:

An IBS translates an intent into derived directives (e.g., allowed rules) that traverse multiple intermediaries before reaching an execution endpoint.¶

Actors:

Intent Originator, Intent Client, IBS, one or more intermediaries (agents/clients), Tool/Service Provider.¶

Assets:

Authorization boundary, constraints/invariants, protected resources, audit evidence.¶

Attack Sketch:

1. A malicious or compromised intermediary node modifies derived directives to add operations or widen resource scope.¶
2. The modified directives are forwarded to the execution endpoint without effective detection.¶
3. The endpoint performs out-of-bound operations (e.g., modifying account state, accessing other parties' data, disabling safety rules).¶

Impact:

Privilege escalation, policy bypass, unauthorized side effects, compliance violations.¶

Relevant Requirements:

R1 (Provenance and Authorization Boundary Binding), R2 (Chain-of-Custody for Derived Directives), R3 (Constraint Validation), R5 (Non-Bypass Enforcement), R6 (Observability and Auditability).¶

Figure 3 illustrates the attack: a malicious or compromised intermediary node tampers with or widens the directive (marked X), and the change is not detected before the execution endpoint performs an out-of-bound operation. The controls that address this attack are discussed in Section 4.3.1.¶

 intent
   |
   v
+--------+      +----------+      +----------+      +------------+
|  IBS   |----->| inter-   |--X-->| inter-   |----->| Execution  |
|        |      | mediary  |      | mediary  |      | Endpoint   |
+--------+      +----------+      +----------+      +-----+------+
                                                         |
  X = malicious / compromised node tampers with or       v
      widens the directive; the change is not        out-of-bound
      detected downstream.                            operation

4.4. Scenario-to-Requirement Mapping

Table 2 summarizes the primary mappings between the scenarios and security requirements. These mappings are non-exhaustive; additional requirements may apply depending on deployment context.¶

5.1. Reference Model Entities

Intent Originator:

The party whose goals and constraints are to be satisfied (e.g., human user, application owner, operator, or delegated principal).¶

Intent Client:

The component that submits intents to an IBS and may carry contextual signals. The Intent Client (or an equivalent admission point) may also enforce origin authentication and originator-level admission control before an intent is forwarded (see R8 and R9).¶

Intent Processing Function:

A logical function that performs translation, validation, and orchestration for intent fulfillment. This function encompasses the Intent Transformer, Constraint Validator, and Invocation Gate.¶

Intent Transformer:

A function that transforms intent representations (e.g., natural language to structured intent, structured intent to constraints/objectives, objectives to derived directives).¶

Constraint Validator:

A function that enforces R3 by validating intents and derived artifacts against constraints, invariants, policy rules, and safety boundaries.¶

Invocation Gate:

A function that enforces R4 and R5 by privilege-checking and constraint-checking each tool/service invocation and preventing bypass of required checks.¶

Policy/Constraint Authority:

A logical source of constraints and policy boundaries (e.g., organizational policy, compliance rules, safety invariants, subscription/contract limits). It also supplies the permission policy that determines which originators may request which services (R9).¶

Tool/Service Provider:

A system that executes actions (APIs, workflows, actuators, management functions, data services).¶

Observer (Monitoring Function):

A function that collects observations (telemetry, events, measurements) used for assurance, compliance assessment, and drift detection (R6 and R7).¶

5.2. Operational Overview

The following informative lifecycle contextualizes admission control, constraint validation, invocation validation, observation, and drift handling.¶

1. The Intent Originator expresses an intent via the Intent Client.¶
2. The Intent Client (or an equivalent admission point) authenticates the origin and applies admission control (R8, R9) before forwarding.¶
3. The Intent Client submits an admitted intent artifact to the IBS.¶
4. The IBS performs intent translation (Intent Transformer) to derive constraints, objectives, and candidate directives.¶
5. The IBS performs constraint validation (R3) in consultation with the Policy/Constraint Authority.¶
6. Prior to each invocation, the IBS performs invocation validation (R4), including privilege checks and parameter/constraint checks.¶
7. The Tool/Service Provider executes the invocation and returns results; side effects may be irreversible.¶
8. The Observer produces observations used by the IBS for assurance and drift detection (R6).¶
9. If drift or violations are detected, the IBS applies a policy-driven response (R7), such as deny, degrade, re-confirm, re-negotiate, or fallback.¶