TL;DR: AI agent security splits into two different controls, according to Trust3: content guardrails can block unsafe prompts and outputs in under 80ms, but they do not decide whether an agent should reach a tool or dataset at all. The harder gap is delegated identity and scope, because A2A chains can carry a request several hops beyond the original agent without a clear access decision.
NHIMG editorial — based on content published by Trust3: AI agent security and A2A monitoring analysis
Questions worth separating out
Q: What breaks when security teams rely on content guardrails to control AI agents?
A: Content guardrails only inspect what an agent says, not what it does.
Q: Why do delegated AI agent chains increase access risk?
A: Because each hop can lose the original task boundary.
Q: What are the signs that AI agent security controls are too weak?
A: Common warning signs include agents accessing systems or data outside their intended scope, sharing sensitive information inappropriately, and using credentials or tools without clear justification.
Practitioner guidance
- Separate content and access control ownership Assign one control path to inspect prompts and outputs and a different control path to decide whether the agent may reach the tool or dataset.
- Propagate identity through every agent hop Require each delegated request to carry task scope, actor context, and provenance through the full chain, including MCP calls and sub-agent handoffs.
- Re-evaluate standing access for agentic workflows Review whether agents hold persistent permissions that outlive the task.
What's in the full article
Trust3's full article covers the operational detail this post intentionally leaves for the source:
- The vendor's side-by-side explanation of inline guardrails versus purpose-based access decisions for agent workflows.
- The specific request-path and tracing model Trust3 says it uses to carry identity through multi-hop A2A chains.
- The operational treatment of JIT grants, scoped execution, and MCP-related handoffs in agent security.
- The vendor's own examples of how its control plane handles delegated requests and correlated audit records.
👉 Read Trust3's analysis of AI agent guardrails, purpose-based access, and A2A security →
AI agent delegation chains: where content guardrails fall short?
Explore further
Content safety is not an authorisation model: Inline guardrails that inspect prompts and outputs solve a narrow class of AI risk, but they do not decide whether an agent should reach a tool or dataset. That distinction matters because identity governance fails when teams assume a clean request is the same as an authorised request. The practitioner implication is to treat content safety and access control as different control families, not interchangeable layers.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, while inadequate monitoring and logging and over-privileged accounts each account for 37%.
A question worth separating out:
Q: Should organisations use content filters or purpose-based access control for AI agents?
A: They need both, but for different reasons. Content filters stop unsafe text and data leakage, while purpose-based access control decides whether the agent is entitled to act at all. If you must choose the first governance priority, start with access control for high-risk tools and data because it blocks misuse before execution.
👉 Read our full editorial: AI agent security needs both content checks and access controls