Decide access outside the model. Your application passes each user’s role to Protecto, which masks sensitive values before the model sees them and reveals only what that role may read.
SOC 2 Type II · ISO 27001 · HIPAA, BAA available
“Summarize the Halvorsen Freight account.”
Control it at every point where data reaches the agent. A rule in the system prompt is a request, not a control.
Never from what the user types. The agent acts on behalf of that user, with that user’s access and no more.
Filter documents before retrieval, use row-level security in the database, and give each role only the tools it needs. This decides which records the agent may read.
One customer record holds a ticket a support engineer needs and a bank account only finance should see. Mask the sensitive values before the model sees them.
The answer shows real values only where this user’s role allows. Everything else stays masked, and the answer still reads normally.
Record who saw which real value, through which agent, and when.
Most teams already have steps 1 and 2. Protecto does steps 3 to 5 in one layer: your application passes the user’s role and task with each call, and Protecto applies your policy the same way in every agent.
Automation Anywhere uses Protecto to apply each enterprise tenant’s policy and reveal original values only when authorized
Live enterprise tenants at Automation Anywhere, each with its own policy
For a Fortune 100 company to enforce data policies across its agent chains, with roles from its existing Active Directory
Lower cost than building it in-house, at a SaaS company
A software company gives its staff one internal account assistant. Support, sales and finance all ask it about the same customers.
On Monday morning three people ask the assistant the same thing: “Summarize the Halvorsen Freight account.” The agent pulls the same CRM record and ticket history for each of them. The record holds what each team needs, and some things only one team should see.
If the agent runs with one service account, all three users get all of it. The support engineer now reads the bank account and the negotiation note. A system prompt line like “do not show billing to support” helps until someone asks the question a different way.
With Protecto in the path, one agent serves all three teams. Pick a role to see what each user reads and what the model receives.
What this user reads
“Marta Kowalski (marta.kowalski@halvorsenfreight.com) has an open ticket on shipment API timeouts since Oct 30. Two retries failed; we are waiting on her log export. Phone and billing details are masked for your role.”
“Open ticket on API timeouts since Oct 30. Renewal is at risk: Marta Kowalski (+1 312 555 0187) said they may not renew if the price rises, after a 28% discount last year.”
“Invoice 8813 was paid late twice. Billing account 4471 0098 2213. A 28% discount applies to the current term.”
The model never holds real values. It reasons over tokens, and Protecto reveals them in the answer per role.
Names and tokens are illustrative. Your policy decides each cell; Protecto applies it.
Classic role-based access control answers “can this user open this record”. An agent needs a finer answer, inside the record and in the text it writes.
Records are mixed. Access control on the data source works on tables, rows or documents. A CRM record, a support thread or a contract mixes values for different roles in one place. Split every record by role and you rebuild your data model for each agent.
The model sees whatever the agent sends. Once a value is in the prompt, the model can repeat it to anyone who asks the right way. Prompt injection, a pasted document or a follow-up question can undo a system prompt rule. The control has to sit before the model and after it.
Every agent rebuilds the same logic. Without a shared layer, each team writes its own masking, role checks and logs. Rules drift between agents, and audit has no single record of who saw what.
For the full background on agents as principals, inherited privileges and multi-agent handoffs, read why role-based access control for AI matters.
Keep the first three. They decide which records an agent reaches. Protecto decides what each user sees inside them.
| Approach | Works inside one record | Same agent, different answer per role | Model gets real values | Context such as deal terms | Log of who saw what |
|---|---|---|---|---|---|
| Rules in the system prompt | Basic. The model decides | Basic. Prompt injection gets around it | Yes, all of them | No | No |
| Retrieval filters and document permissions | No. Whole documents in or out | Yes, at document level | Yes, for allowed documents | No | Basic. Retrieval logs only |
| Database row and column security | Basic. Fixed columns, not free text | Yes, for structured fields | Yes, for allowed fields | No | Basic. Database logs only |
| Field masking in the data store | Basic. Fixed fields only | No. Masked the same way for every reader | No, and no one can see real values later | No | Basic |
| Protecto | Yes. Finds sensitive values in free text and fields | Yes. Reveals per user, agent and task | No. Tokens only; real values stay in your environment | Yes, with Context-Based Access Control | Yes. Every mask and reveal logged |
Based on common practice and public documentation, reviewed November 2026.
Your application decides who the user is. Protecto applies that user’s access to every value the agent touches.
With each call, your application passes an auth key carrying who is asking, which agent, the task, and what that role may see. Roles come from your own identity system: Active Directory, then your application, then Protecto.
Its agentic detection and classification engine finds sensitive values in prompts, retrieved context and tool outputs, and replaces them with consistent tokens such as <PERSON>Kq7Lm2 Rv9Tx</PERSON>. The model reasons over the tokens, so the answer stays accurate.
Passages that are sensitive by meaning, such as discount terms, legal strategy or HR notes, stay out of the answer for roles that may not see them.
Values the role may see are unmasked in the answer; the rest stay masked. Every mask and reveal is logged with who, which agent and when.
When a rule changes, update the policy context your application passes; agent code stays the same. Call Protecto from LangChain, LlamaIndex or your own code. Role-based access control for AI agents →
No. A system prompt rule is an instruction the model may not follow. A rephrased question, a pasted document or a prompt injection can get around it. Access has to be enforced in code, before data reaches the model and before the answer reaches the user.
It decides which records an agent can read. It does not decide which values inside an allowed record each user may see, and it does not stop real values from reaching the external model. Keep it, and add a layer that masks and reveals values per role.
The value stays masked. The answer still reads normally, for example “phone and billing details are masked for your role”, so the user gets a useful answer without the data they may not see.
No. Protecto replaces sensitive values with tokens before the model. Real values stay in your environment and are revealed only in the answer, only to users whose role allows it.
Yes, through Protecto AI Privacy Gateway. You keep each user’s masking and unmasking access in AD or Okta groups, and Gateway issues a Protecto auth key with that access at login. If you use Protecto Vault directly, it’s a headless API, so your team can build the integration around it.
Masking handles values such as names, account numbers and emails. Context that is sensitive by meaning needs Context-Based Access Control, an add-on to Protecto Vault, which keeps those passages out of answers for roles that may not see them.
No. Rules live in the policy context your application passes with each call. Change the policy and every agent that calls Protecto applies it.
Yes. Protecto logs every mask and every reveal, with who asked, through which agent and when, so audit can answer “who saw this customer’s bank account” from one record.
Bring one agent and two roles. We will show what each user sees, what the model receives and what the log records.
