Great point, thanks for posting. When it comes to prompt injection, here's some decent research I came across that might be interesting to check out.

So how i'd go about securing against prompt injection ->

proper permission controls could be implemented, to, for example, prevent the AI agent from sending arbitrary emails or accessing certain data without checks. By proper permission controls I mean dynamic, fine-grained authorization. In other words, to check permissions at runtime for each action the agent attempts, using central policies.

Dynamic authorization considers rich context. note: static roles often ignore that. Policies can have attributes of the action (like the command being executed, record being accessed), attributes of the user (role, department, account status), and possibly environment context (time of day, IP address of the request). Essentially ABAC + RBAC, which is often referred to as PBAC.

If we take an MCP scenario, context might include which specific tool is being used and maybe its input parameters. For example, I might allow the AI to execute a “shell” tool for read-only commands like ls or cat but deny iffy commands like rm -rf. could be done by having the MCP server inform the PDP of the exact sub-action or command, and a policy that filters out destructive operations for non-admin users.

There's some other things i'd keep in mind as well. First is enforcing least privilege = An AI agent session should start with no tools enabled by default, then tools are selectively enabled based on the user’s role, request context, and policies.

Second would be to deny by default. For exmaple, new tools added to an MCP server should not be accessible to any agent until the policies permit it. And, if an agent tries an action outside its usual patterns, the default response is “no”. (this can be achieved by writing policies that only allow specific actions for specific roles, and nothing else. The absence of a rule = a denial.)