AI data entitlement: Why a prompt is not secure

A prompt can be talked into anything. Here's how we stopped an AI agent from reading data it shouldn't have access to.

Which question sabotages most AI agent projects?

Part 3 in our series When LLMs meet enterprise data is about the single question that often sabotages AI-agent-on-top-of-your-data projects. It isn't, “Is the model good enough?”

It's the entitlement question: “What data is this AI agent actually entitled to reach, and what stops it from obeying a command like, ‘Show me everyone's records’”?

Every demo dodges this dilemma. The demo has one user, friendly data, and nobody asks the agent to misbehave. But then you ship it to an enterprise, with real customers and real regulators, and someone on the security team asks the question, and if your answer is, "Well, we told the model in the system prompt to only access the current user's data," you've already lost. You just don't know it yet.

Here's the principle that's easy to lose sight of when the demo is sailing along: a prompt is not a security boundary. It can't be. We've spent two years watching people talk LLMs out of their instructions with everything from, "Ignore previous instructions," to elaborate roleplay.

An instruction in a prompt is a strong
suggestion to a very agreeable system.

It's not access control. If the only thing standing between an agent and your entire customer base is a politely-worded paragraph, you don't have security – you have a hope.

So, we moved the boundary completely out of the model. The agent doesn't get told, "Please be good." The agent is structurally incapable of reaching data it shouldn't, because entitlement is decided below it – in the data layer, enforced by the platform.

Where should the security boundary live?

In the token, not in prompt engineering techniques. When an agent acts on behalf of a user, it carries a JSON Web Token (JWT) – a signed, tamper-evident credential – and two things in that token do the real work.

1. Role

   The token the agent server presents maps to a role that has read permission and nothing more. The agent can look at data and reason about it. It can't change anything. That single constraint removes a whole category of risk. The "What if the agent gets convinced to delete a record?" worry simply doesn't apply, because the credential it's holding can't write.

2. Entity claim

   The token carries a claim that pins exactly which business entity it's allowed to attach to. A business entity is the real-world thing your business is organized around – a single customer, order, or loan – and at K2view all the data for one entity lives in its own Micro-Database™ (the data-lake-of-one we covered in Part 1). One token maps to one entity, period.
   
   

   
   

   So when the agent tries to pull data, the platform checks whether this token is scoped to this particular customer. If not, it returns nothing. The data for every other customer isn't blocked by a rule the agent might argue its way past – it's simply not reachable through that token. 

How we do it 

 K2view accepts standard OAuth2 / JWT bearer tokens from any compliant identity provider (Cognito, Auth0, Okta, Keycloak, Azure AD, and the like). The token's claims map onto the K2view roles-and-permissions model, so the role in the token decides what operations are allowed. You scope the agent server's role to read-only at the platform level – not in the prompt.

The entity pinning is the elegant part. With K2view, AI access goes through per-entity MCP AI sessions, and the entity session is bound to a value that comes straight from a JWT claim (the pattern looks like k2_data_product_{dp_name}: "{instance_id}").

So, the token itself declares, "This session is for customer C-12345." Combined with K2view's per-entity access control – where a role grants access to an entity type and instance rather than to a global table – the agent inherits exactly the entitlement of the human it represents.

That last point is the one worth sitting with: the same Role-Based Access Control (RBAC) that governs human access governs the agent. There's no separate, weaker AI auth path to exploit.

The lesson 

 The lesson is an old one, and the LLM era just made it urgent again: identity and entitlement belong below the application, never inside it – and never inside a prompt.

The reason this matters more with LLM agents than with ordinary apps is that agents are designed to be talked into things. That's the whole point of them. So, the boundary has to sit somewhere the conversation can't reach. Scope the token, enforce at the data layer, and the agent doesn't need to be trusted to behave. It simply can't misbehave in the one way that matters.

Coming soon: “AI agents and the importance of separation of duties”