Teams lose the distinction between observation and intent, so agents may act on noise instead of a verified change that requires action. Raw telemetry is useful for monitoring, but not for orchestration. Without explicit directives and responses, the workflow cannot reliably confirm whether a task should proceed or stop.
Why This Matters for Security Teams
When agent messages are treated as raw telemetry, the control plane and the observation plane get blurred. That sounds harmless until an autonomous workflow starts treating logs, traces, or alerts as if they were explicit instructions. In agentic systems, a message is not just data. It can carry intent, priority, or a request to use tools. If that distinction is lost, the system can escalate noise into action, or ignore a real directive because it looked like ordinary telemetry.
This matters most where agents operate across security operations, cloud automation, or customer-facing workflows. The failure mode is not limited to one model or vendor. It is a design issue in how trust, memory, and action are separated. Guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point to the need for bounded behaviour, provenance, and human accountability around agent actions.
In practice, many security teams discover this only after an agent has already executed a tool call based on an unverified status update rather than through intentional orchestration.
How It Works in Practice
A healthy agent workflow separates three things: observation, interpretation, and action. Telemetry belongs in the observation layer. It informs detection, state awareness, and audit trails. It should not, by itself, be treated as a command. Agent messages, by contrast, need explicit structure so the receiving system can determine whether the content is a directive, a status update, a retry signal, or a request for approval.
In operational terms, this usually means agents should exchange messages with defined schemas, confidence markers, and policy checks before any action is taken. A SOC automation agent, for example, might receive an alert that says suspicious login activity increased. That alert is telemetry. It becomes actionable only when a rule engine, approval workflow, or policy layer confirms the next step. Without that gate, the agent may start containment actions on weak evidence or duplicate work already in progress.
Useful patterns include:
- Tagging messages by type, such as telemetry, instruction, decision, or acknowledgement.
- Validating the source and integrity of every instruction before tool use.
- Keeping a separate audit trail for observed events versus executed actions.
- Applying policy checks before the agent can turn a message into a state change.
The MITRE ATLAS adversarial AI threat matrix is useful here because prompt injection, message tampering, and context poisoning often exploit weak message boundaries. The CSA MAESTRO agentic AI threat modeling framework also helps teams reason about where autonomy should stop and where human or policy approval must begin. These controls tend to break down when event streams from multiple systems are merged into a single shared context because the agent can no longer distinguish operational state from intended instruction.
Common Variations and Edge Cases
Tighter message validation often increases latency and integration overhead, requiring organisations to balance autonomy against control. That tradeoff is real, especially in high-volume environments where teams want fast response but cannot afford ambiguous action paths. Best practice is evolving, but there is no universal standard yet for how much structure every agent message should carry.
Some environments do tolerate looser handling, but only when the downstream action is low risk and reversible. A read-only summarisation agent can safely consume telemetry as context because it is not changing systems. A remediation agent cannot. The more privilege an agent holds, the less acceptable it is to blur telemetry and intent. That is especially true where the workflow touches secrets, deployment pipelines, identity changes, or security containment actions.
Another edge case is natural language coordination between agents. Current guidance suggests that free-form text should be treated as untrusted unless it is wrapped in a policy-controlled message format. Otherwise, a benign operational note can be misread as a directive. The right response is not to ban rich language, but to constrain where it can trigger action and where it remains advisory only. For more context on agent-specific risk patterns, practitioners should read the OWASP Top 10 for Agentic Applications 2026 and the Anthropic report on the first AI-orchestrated cyber espionage campaign report, which shows how quickly context manipulation can become operational abuse.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, MITRE ATLAS and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST AI 600-1 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Agent message confusion maps to prompt injection and unsafe action boundaries. | |
| NIST AI RMF | AI RMF govern and map functions fit message provenance and accountability controls. | |
| MITRE ATLAS | Adversarial context poisoning and message tampering are core ATLAS concerns. | |
| CSA MAESTRO | MAESTRO addresses where agent autonomy should stop and approvals must start. | |
| NIST AI 600-1 | GenAI profile guidance reinforces output handling and trust boundaries for agents. |
Separate telemetry from directives and require validation before any tool-triggered action.