Topic starter
01/08/2026 9:00 pm
TL;DR: Runtime detection, traceability, and inline blocking across Claude Chat, Cowork, and Code can catch attacks, according to Straikerai research, but indirect prompt injection through Skills, connectors, and MCP servers shows why untrusted content has become an execution path, not just a prompt. Runtime controls help, but governance must move upstream to what agents are allowed to load and execute.
Editorial analysis by NHI Mgmt Group, based on content published by Straikerai: “How Straiker Secures Claude with the Claude Compliance API”.
Key questions
Q: What breaks when indirect prompt injection reaches an agent through Skills or MCP servers?
A: The main failure is that the agent treats untrusted content as operational context and may execute instructions that were never meant to be authorised.
Q: Why does indirect prompt injection create more risk than a malformed request in AI applications?
A: Indirect prompt injection is risky because the payload arrives as ordinary content, such as a support ticket, document, or code comment.
Q: How should security teams implement agent controls when runtime blocking is already in place?
A: They should treat runtime blocking as a containment layer and build upstream controls around it.
Practitioner guidance
- Inventory every agent-accessible Skill and MCP server Catalogue each Skill, connector, and MCP endpoint a Claude workflow can reach, then classify the trust level, data exposure, and execution potential for each one.
- Move policy to pre-execution allowlisting Permit only the tools, documents, and servers the agent is explicitly authorised to use, and block unknown content sources before they enter the session context.
- Correlate session traces with identity and tool events Store prompts, tool calls, and content sources together so investigators can reconstruct which user, agent, and delegated service identity participated in the action.
Bottom line: Indirect prompt injection works because trusted agent inputs can become executable instructions after they are loaded into context.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
01/08/2026 9:07 pm
Runtime agent security is necessary, but it is not the control plane. Detection and blocking at execution time can limit blast radius, yet they assume the dangerous path has already been admitted into the agent workflow. That is why agent governance has to extend to what content and tools the system can ingest before any action is taken. Practitioners should treat runtime as containment, not consent.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: How do security teams know if agent observability is actually working?
A: Observability is working only when teams can tie together token activity, tool calls, and latency for a specific agent session. If those signals are disconnected, the logs may show traffic but not governance. The test is whether investigators can reconstruct the path of a meaningful agent action from start to finish.
👉 Read our full editorial: Claude compliance API coverage exposes the limits of runtime agent security