AI security still lacks a shared vocabulary, but prompt injection does

At a glance

What this is: This is an analyst-style post arguing that AI security remains fragmented as a category, while prompt injection is the most consistent control failure across agentic systems.

Why it matters: It matters to IAM and security teams because agent behaviour, tool access, and delegated execution now create identity-like trust boundaries that need runtime governance, not just visibility.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Impart's analysis of AI security vocabulary and prompt injection risk

Context

AI security is not one control problem. It is a cluster of distinct problems that include prompt injection, runtime enforcement, data exposure, and the governance of AI systems that can act with delegated access. The article argues that the market is still naming these problems inconsistently, which makes it harder for buyers to map tools to the real failure mode.

That vocabulary gap matters because many AI systems now behave like identity-bearing software entities. When a browser agent, coding agent, or MCP-connected workflow can accept instructions and trigger downstream actions, the security question shifts from model quality alone to who or what is allowed to act, on what data, and under which runtime boundary.

For IAM and NHI practitioners, this is familiar territory in a new form: the boundary is no longer only a user session or service account, but an AI-driven execution path that can inherit trust too easily. The article’s starting position is typical of the current market, where visibility is improving faster than control design.

Key questions

Q: How should security teams govern AI agents that can choose tools at runtime?

A: Security teams should govern runtime agent choice as an access event, not as a simple application action. That means scoping permissions to the task, limiting token lifetime, logging every tool decision, and blocking the agent from reaching systems outside its approved context. Static roles alone are not enough when the execution path changes on each run.

Q: Why do prompt injections matter so much in AI security programmes?

A: They matter because they exploit a trust failure, not just a content issue. If a system cannot distinguish between trusted instructions and untrusted text, any connected tool, browser action, or workflow can be steered into unintended behaviour. That makes prompt injection a governance problem as much as a technical one.

Q: How do you know whether AI observability is actually reducing risk?

A: Look for evidence that the programme can stop unsafe actions, not only reconstruct them. If teams can see prompts and tool calls but cannot block execution before completion, observability is improving awareness without materially reducing exposure. The key signal is whether policy is enforced at runtime.

Q: What is the difference between monitoring AI behaviour and controlling it?

A: Monitoring tells you what happened after the fact. Controlling means the environment can prevent, limit, or redirect the action before it completes. In practice, that difference determines whether the organisation has a forensic capability or a true enforcement boundary for AI-driven workflows.

Technical breakdown

Why prompt injection breaks instruction boundaries in agentic systems

Prompt injection works because many AI systems treat retrieved or encountered content as if it were trustworthy instruction. A browser agent, coding assistant, or MCP-connected workflow can ingest text that was never intended as policy and then execute it as if it were part of the task. The technical failure is not just malicious text. It is the absence of a hard separation between data, instructions, and tool invocation. Once the model or orchestrator cannot reliably distinguish those roles, the system becomes steerable by untrusted content in its environment.

Practical implication: enforce explicit instruction and data boundaries before untrusted content can reach tool execution.

Why observability does not equal runtime control

Observability systems reconstruct what an AI agent did after the fact, including prompt, reasoning trace, tool calls, and outcome. That is valuable for forensics and tuning, but it does not prevent a harmful action from completing. Runtime control sits earlier in the chain and can block, constrain, or condition tool use before the request finishes. This distinction matters because many current AI security products focus on detection, while the real control question is whether the environment can stop a delegated action mid-flight.

Practical implication: separate detection workflows from enforcement points and require a block-or-allow decision at execution time.

MCP trust assumptions are becoming an identity problem

Model Context Protocol extends the trust surface by letting agents connect to tools and data sources through standard interfaces. That is useful operationally, but it also creates an identity and authorization problem: if the system over-trusts the connector, it may over-trust the content returned by that connector. In practice, MCP security depends on whether the surrounding architecture can govern least privilege, provenance, and tool-scoped permissions with enough precision to prevent instruction laundering.

Practical implication: treat MCP endpoints as privileged integration points and bind them to scoped authorization and provenance checks.

Threat narrative

Attacker objective: The attacker wants to steer an AI system into executing actions that were never authorised by the human or the security team.

1. Entry occurs when an agent ingests untrusted content from a webpage, file, or tool response that contains hidden instructions.
2. Escalation follows when the agent treats that content as executable guidance and invokes connected tools with inherited trust.
3. Impact occurs when the agent completes unintended actions, exposing data, modifying systems, or triggering downstream workflows outside the intended boundary.

NHI Mgmt Group analysis

Prompt injection is the category’s shared failure mode, not just one more AI bug. The article is right to collapse browser agents, coding agents, and MCP-connected workflows into a single control problem. The delivery mechanism changes, but the underlying issue is the same: a system built to follow instructions cannot reliably separate instruction from untrusted content. That makes prompt injection the most citable security concept in this space, and it should be used as the anchor for policy design, red teaming, and architecture reviews.

AI security vocabulary is still fragmenting governance. Buyers are being asked to compare tools that solve detection, filtering, enforcement, or model safety as if they were interchangeable. They are not. In governance terms, this is a classification problem as much as a control problem, because programme owners need to decide whether they are protecting prompts, models, tool calls, or delegated execution paths. Practitioners should map each tool to the exact failure mode it covers, then reject any control strategy that cannot name its boundary.

AI agents are already behaving like non-human identities when they inherit access. That is the identity bridge the market still underestimates. Once an AI system can choose actions and invoke tools, the question becomes closer to NHI governance than traditional application security, because the runtime entity now has permissions, context, and a trust relationship that must be controlled. The organisation that treats these systems as identity-bearing workloads will design better boundaries than the one that treats them as just another model integration.

Visibility-first programmes will stall if they confuse telemetry with containment. The article captures a common market trap: teams can now see more of what agents do, but they still cannot reliably stop bad actions before completion. That gap is where governance matures or fails. The next phase of the market will favour controls that can enforce task-scoped privilege, tool-level authorization, and decision-time blocking rather than post-hoc analytics alone.

Named concept: instruction boundary drift. This describes the moment when untrusted content, connector output, or agent context is misread as legitimate instruction. It is a useful shorthand for the failure pattern that underlies prompt injection, MCP trust mistakes, and agent overreach. Security teams should use the concept to test whether their architecture actually preserves a hard line between data, advice, and action.

What this signals

Instruction boundary drift will become a useful operating concept for teams that need to distinguish safe context from unsafe execution. As AI agents spread across browsers, developer tools, and MCP-connected workflows, security teams will need a clearer policy model for when content becomes action.

The practical next step is to align AI control design with established security thinking from NIST SP 800-53 Rev 5 Security and Privacy Controls and OWASP Agentic AI Top 10. That combination helps teams map runtime enforcement, privilege scope, and injection resistance into a single programme view.

For practitioners

• Define instruction boundary enforcement Classify which inputs an agent may read, which it may treat as instructions, and which must remain data only. Apply that separation consistently across browser agents, coding assistants, and MCP-connected workflows.
• Add runtime stop points before tool execution Require an allow, deny, or constrain decision at the point where an agent is about to call a tool. Post-event logging is useful, but it cannot prevent a completed action.
• Scope MCP integrations to least privilege Treat each MCP server or connector as a privileged integration. Limit tool permissions, restrict data exposure, and verify provenance before the agent can act on returned content.
• Separate monitoring from enforcement Use observability to reconstruct sessions, but do not mistake telemetry for control. Build policy gates that can block unsafe requests even when the model appears confident.

Key takeaways

• AI security is fragmenting into separate control domains, and prompt injection is the clearest shared failure mode across them.
• Visibility into agent behaviour is not enough on its own, because telemetry cannot stop an unsafe action before it completes.
• Practitioners should govern AI systems like delegated execution paths, with instruction boundaries, runtime blocking, and least-privilege tool access.

Key terms

• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads — causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• MCP: Model Context Protocol, an open way for AI agents to connect to tools and data sources. It improves interoperability, but it also introduces a shared integration layer that must be governed carefully because the protocol can widen access across many systems at once.
• Instruction Boundary: The line between content the model should interpret and directives it should obey. In practice, this boundary is often blurred when workflows mix user data, embedded instructions, and tool permissions in one session. Strong governance depends on keeping that boundary explicit and enforceable.
• Runtime Enforcement: Runtime enforcement is the practice of blocking malicious behaviour while software is running, rather than only detecting it after the fact. It monitors process activity, network actions, and privilege changes so a live attack can be interrupted at the point of execution.

What's in the full article

Impart's full blog post covers the operational detail this post intentionally leaves for the source:

• How the vendor distinguishes AI gateways, AI firewalls, browser agent security, and MCP security in practice
• The specific runtime enforcement approach it argues is needed before a request completes
• Examples from Black Hat and Ai4 conversations that show how buyers are framing the problem
• The vendor’s own view of where visibility stops and blocking begins

👉 Impart's full post expands on the runtime control gap, AI security category split, and agent trust assumptions.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and agentic AI identity. It gives security practitioners a structured way to connect delegated access, lifecycle control, and runtime governance.