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

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

jiangyuning2@h-partners.com

Huawei

lilun20@huawei.com

Huawei

songyurong1@huawei.com

Huawei

liufei19@huawei.com

Security intent AI Agents agentic systems delegation transaction context drift Intent-based requests enable users, applications, and agents to express goals and constraints without specifying step-by-step procedures. Such intents are commonly translated into executable directives and propagated across multiple entities (clients, agents, authorization components, orchestration functions, and execution endpoints). This multi-hop processing expands the attack surface for tampering, privilege escalation, constraint bypass, and intent drift. In addition, at the point where an intent enters the system, a forged or unauthorized origin may cause actions to be taken without valid consent. This document provides a solution-agnostic security analysis for intent-based requests across agentic systems. It presents attack scenarios, a threat model, security requirements, and per-scenario mitigation considerations, supported by a reference model. The document is Informational: it does not define a protocol, message format, or registry, and concrete mechanisms are left to companion specifications. It emphasizes origin authentication and admission control, constraint validation, invocation validation, multi-hop chain-of-custody, enforcement placement across hops, and policy-driven responses to drift, while remaining independent of any specific deployment domain.

Introduction Intent-based interaction is increasingly adopted in automation, orchestration, and agentic systems, where a request expresses desired outcomes and constraints rather than explicit procedures. A receiving system (or a chain of systems) translates the intent into executable directives and invokes tools or services to achieve the intended outcome. Multi-hop processing (client-to-agent, agent-to-agent, agent-to-tool/service) introduces security risks beyond traditional single-hop APIs, including: (1) integrity and substitution attacks against derived directives, (2) privilege escalation during tool/service invocation, (3) constraint bypass, (4) multi-hop intent drift where constraints degrade or diverge over transformations, and (5) admission-time risks where an intent of spoofed or unauthorized origin is accepted and acted upon without valid consent. This document does not define a new protocol. It provides a security-oriented threat analysis, security requirements, attack scenarios with mitigation considerations, and a reference model to support future standardization and interoperable designs. Concrete mechanisms (message formats, token claims, processing rules, registries) are out of scope and are expected to be specified in companion documents. The document leads with the attack scenarios; the reference model is provided later as supporting structure.

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 , focusing specifically on intent origin, multi-hop directive integrity, and drift.

Terminology and Conventions

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 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.

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 and its use cases .
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 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.

Acronyms

IBN:: Intent-Based Networking
IBS:: Intent-Based System

Problem Statement and Threat Model In many agentic systems, an intent is translated into executable directives (e.g., an allowed rule set) that must be propagated across multiple entities and enforced at execution endpoints. However, existing designs often lack end-to-end mechanisms that jointly ensure: (1) the intent originates from an authenticated and authorized originator and has obtained any required consent before admission, (2) directives remain within authorized boundaries across transformations and propagation, (3) constraints are validated before execution, (4) invocations are privilege-checked and constraint-checked at each call boundary, and (5) drift is detected and handled under policy.

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 (). 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.

Illustrative sequential multi-agent processing illustrates one such pattern, the sequential orchestration of the Microsoft Agent Framework , 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:

Agent Pipeline: agents are arranged in a predefined sequence where output from one agent becomes input for the next.
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.
Human-in-the-Loop: optional approval points for sensitive operations (e.g., tools marked as approval-required).
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.

Threats With reference to the illustrative pattern in , 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.

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 ). 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.

Security Scenarios and Mitigation Considerations This section describes representative security scenarios and abstract mitigation considerations. Each scenario uses a consistent template (Setting, Actors, Assets, Attack Sketch, Impact, Relevant Requirements) followed by mitigation considerations. The considerations indicate the class of control point where a problem may be addressed; they do not define concrete mechanisms, message formats, or processing rules, which are left to companion documents. first establishes a common enforcement-placement model that both scenarios rely on.

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).

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:

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.
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).

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 .

Scenario 1: spoofed/unauthorized origin attack (X) high-impact action on a +-----------------------+ spoofed / unauthorized intent (X) = spoofed or unauthorized origin ]]>

Mitigation Considerations Following, origin and consent are best evaluated at the earliest admission point, because the relevant signals (which application or agent originated the intent, its execution context, whether the user is present and consenting) are typically only verifiable there; once the intent crosses into the network or a relay, these signals cannot be reconstructed. The admission decision can then be conveyed in an Admission Assertion that the execution endpoint re-verifies before acting (non-bypass, R5). Admission decisions draw on risk-relevant originator attributes, such as originator identifier, originator class, execution context, attested application/workload state, or locally maintained risk signals, subject to privacy policy. Execution context or user-presence state, where available, such as foreground interaction, unattended execution, delegated background execution, or scheduled automation, can inform the decision. The decision is evaluated against a permission policy expressing which originators may request which services. For high-impact or irreversible actions, explicit user consent is obtained and verified. A concrete encoding of an Admission Assertion (claims, format) and the associated processing rules are out of scope for this document and are expected to be specified in a companion mechanism document. Candidate building blocks include token formats such as and the agent-to-agent OAuth profile .

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:

A malicious or compromised intermediary node modifies derived directives to add operations or widen resource scope.
The modified directives are forwarded to the execution endpoint without effective detection.
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).

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 .

Mitigation Considerations Because transport security protects the link but not a malicious intermediary node (T1), derived directives are treated as security-relevant artifacts whose integrity and authorization-boundary binding are protected across hops, independently of any hop-by-hop secure channel. At the architectural level, and following the hybrid placement of , the relevant control points are:

Binding and custody (R1, R2):: Derived directives are bound to the intent context and authorization boundary so that unauthorized expansion or substitution is detectable or preventable across hops, with the binding surviving relays end-to-end.
Per-boundary verification:: At each trust-boundary crossing, a transforming hop re-validates and may only attenuate (never widen) the authorization boundary before re-binding.
Endpoint re-validation (R3, R5):: The execution endpoint re-verifies the binding and re-validates the directives against local constraints as the authoritative, non-bypassable gate, providing defense-in-depth even if upstream validation was bypassed or compromised.
Audit evidence (R6):: The system produces evidence linking execution decisions to validated directives and constraints.

This addresses T1 (Directive Tampering/Substitution) and T3 (Constraint Bypass). A concrete encoding for the binding and custody evidence (e.g., specific token formats or attenuation mechanisms) is out of scope for this document. Candidate building blocks for carrying authorization context and chain-of-custody across hops include transaction tokens and their agent profile . The semantic fidelity of an intent degrades along the transformation pipeline (natural-language intent, structured intent, constraints/objectives, derived directives, invocation parameters). Once an intent is reduced to directives, the original meaning may no longer be recoverable from the directive alone. Verifying that a concrete action still falls within the original intent therefore requires a representation of the original intent's constraint envelope to be carried alongside the directives to the point of check. Hops may then be treated by role: Per-Hop Roles in a Multi-Hop Chain

Hop role	Action on the intent/directive	Semantic-consistency check
Relay-only (proxy, API relay)	Verifies binding/integrity and forwards; is not trusted to preserve intent, so binding is end-to-end.	None (does not transform).
Transforming hop (re-plans/rewrites)	Re-validates against constraints; may only attenuate (never widen) the authorization boundary; re-binds with chained custody.	Checks the transformed result against the carried intent envelope.
Execution endpoint (Invocation Gate)	Re-verifies binding, re-validates local constraints, enforces non-bypass.	Mandatory: checks the concrete invocation against the carried intent envelope.

Scenario-to-Requirement Mapping summarizes the primary mappings between the scenarios and security requirements. These mappings are non-exhaustive; additional requirements may apply depending on deployment context. Scenario to Requirement Mapping

Scenario	Primary Threats	Key Requirements
1 (Spoofed/Non-Consensual Origin)	T6, T7	R8, R9, R3, R6
2 (Directive Tampering)	T1, T3	R1, R2, R3, R5, R6

Reference Model This section provides a technology-neutral reference model that underpins the scenarios above. It is aligned with intent-based system decomposition commonly used in IBN guidance , while remaining applicable to non-networking domains. The model is logical: a deployment may collapse functions into fewer components or distribute them across multiple agents and services, and multi-hop chains are formed by composing instances of the model (an intermediary acts as a provider to its predecessor and as a client to its successor).

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).

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

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

Security and Privacy Considerations Beyond the scenario-specific considerations, the following general principles apply to intent-based systems:

Trust Boundary Awareness: systems explicitly identify trust boundaries and apply appropriate security controls at each boundary crossing.
Defense in Depth: validation occurs at multiple layers (admission, translation, propagation, invocation, execution) to provide resilience against bypass or compromise of individual layers.
Least Privilege: derived directives and invocations are scoped to the minimum privileges necessary for intent fulfillment.
Fail-Safe Defaults: when validation fails or drift is detected, systems default to denying actions rather than permitting potentially unsafe operations.
Auditability: all security-relevant decisions and events are logged with sufficient context to support post-incident investigation and compliance assessment.
Privacy of Admission Signals: admission assertions should avoid exposing raw local state or behavioral history to downstream entities; coarse-grained decisions or policy references are preferred over detailed originator profiles. Risk-relevant attributes are minimized and subject to privacy policy.

IANA Considerations This document has no IANA actions. It does not define any message format, claim, or registry; concrete admission and binding mechanisms, and any associated registrations, are out of scope and would be specified in companion documents.

Normative References Informative References Sequential Orchestration, Microsoft Agent Framework Workflows Microsoft Microsoft, cited as an illustrative example only Semantic Conventions for Generative AI (GenAI) OpenTelemetry Authors OpenTelemetry, work in progress (experimental)

Acknowledgments The authors thank Adam Lin (Agent Threat Rules) for implementer feedback on the observability and drift-detection requirements (), in particular the observations that audit evidence benefits from a shared, interoperable trace schema and that an absent expected control is a detection shape distinct from a violated constraint.