Notifications
Clear all
Topic starter
19/08/2026 3:24 pm
TL;DR: Azure OpenAI prompt-injection controls cover only a boundary of the agent stack, with agent-level guardrails applying to Foundry Agent Service and model-side settings not merging into them, according to ARMO. The practical issue is not classifier quality but control scope: many production agents still execute outside the intervention points teams assume are active.
NHIMG editorial — based on content published by ARMO: Azure OpenAI Prompt Injection: What Prompt Shields Misses
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should security teams govern AI agents that call APIs instead of using a UI?
A: Security teams should govern AI agents by treating each callable action as a scoped entitlement, not as a general application login.
Q: Why do prompt injection controls fail when agents inherit the wrong guardrail scope?
A: They fail because the control plane you configured may not be the control plane the agent actually uses.
Q: What do teams get wrong about model-side prompt filters and agent security?
A: They assume content filtering alone secures the full agent lifecycle.
Practitioner guidance
- Map each agent to its effective interception points Document whether the workload is a custom orchestrator, a Foundry standard agent, or a hosted agent, then record which content inspection points actually apply.
- Audit delegated identity and egress together Review the managed identity, Key Vault access, storage permissions, and outbound destinations each agent can use.
- Instrument runtime behaviour for deviation detection Collect process execution, system call, file access, and network telemetry for each agent workload, then baseline normal tool usage and destination patterns.
What's in the full article
ARMO's full analysis covers the operational detail this post intentionally leaves for the source:
- The documented Azure guardrail tables that show which intervention points apply to models and which apply to agents.
- The configuration paths for custom orchestrators, Foundry standard agents, and hosted agents so teams can compare coverage by build pattern.
- The troubleshooting notes and control-state examples that help prove whether an agent is actually scanning tool calls and tool responses.
- The runtime telemetry guidance for per-agent behavioural baselines and deviation detection.
👉 Read ARMO's analysis of Azure OpenAI prompt injection guardrail scope →
Azure OpenAI prompt injection: are your agent controls actually scoped?
Explore further
19/08/2026 4:09 pm
Agent guardrail scope is now an identity governance problem. When an AI agent’s effective controls depend on where it was built, which guardrail was assigned, and whether tool-plane inspection exists, governance can no longer stop at model policy. The practical issue for identity teams is that a legitimate workload identity can still be the execution vehicle for a coerced action. That makes policy inheritance, control scope, and delegated execution part of the same governance conversation. Practitioners should treat agent guardrail scope as an access boundary, not a UI setting.
A question worth separating out:
Q: How do organizations prove AI agent controls are actually working?
A: Organizations prove control effectiveness by showing which agents accessed which data, what actions they executed, and whether those actions stayed within approved task boundaries. Useful evidence includes logs, policy decisions, anomaly alerts, and review records. Without that chain, governance is mostly declarative.
👉 Read our full editorial: Azure OpenAI prompt injection exposes agent guardrail blind spots
