Every vendor says its agent respects your permissions. Ask how. Too often, the answer is a paragraph in the system prompt: do not disclose salaries, do not reveal supplier prices. That paragraph is an instruction, and the user on the other side can type instructions too.
A prompt is a request, not a right
The system prompt and the user’s question reach the model through the same channel. The policy is a sentence, the attack is a sentence, and the more persuasive one wins. A better model does not solve this: following instructions well is precisely what it is built to do.
A right works differently. A field is visible to a given person or it is not, and the institution settled that before the question was asked, through its directory, its clearances, its contracts. An agent that carries a paraphrase of those rules in its prompt is enforcing the law from memory.
Guardrails act after the data was read
The second common answer is a guardrail: a filter that inspects the agent’s output and removes what should not leave. By then, the data has already been retrieved and reasoned over. The guardrail only decides whether it gets mentioned, and it decides on a probability.
A right applies before the read. What enters the agent’s context is the real security question. An organisation that cannot say what its agent read cannot defend it before a regulator or a court.[1] [2]
A perimeter has two settings
The third answer is the network perimeter: run the agent inside, give it a service account, rely on the walls. A perimeter offers two settings, everything or nothing, which is why so little ever gets shared.[3]
Many situations need finer control. A prime contractor and its subcontractor, or a bank and its regulator, need the same facts at different depths. Governing access at the level of each field and each relation lets one model serve both, showing each exactly what they are entitled to see. A perimeter forces you to copy the data, degrade the copy and lose the link between the two versions.[3:1]
Aggregation raises the same problem. Two unclassified facts can combine into a classified one: a fleet’s position and its readiness are each shareable, together they are not. The classification belongs to the relation, and a perimeter has nowhere to record it.[3:2]
A log is not a permission
Audit logs are necessary: a tamper-resistant record of every input, model call, tool execution and output. But a log records what was read. It cannot decide what may be read, and by the time the entry exists, the answer is already on screen.
Lawful use of AI requires three things: every query logged, every access scoped to a purpose, every action attributable to a named person.[4] The log covers the first. The second requires rights that exist before the query. The third requires a person, not a service account.
Our position
Galahad does not treat a system prompt as an access policy, a guardrail as a substitute for rights, or a perimeter as governance.
In Monarch, access rights are enforced by the database, and each deployment serves a single organisation.[5] The agent inherits the institution’s decisions. It does not carry a copy of them.
Questions to ask a vendor
Ask them before the agent is connected to anything.
- Where is the rule for who may see this field: in the prompt, in the application, or in your own access system?
- If I revoke a user’s right in my directory, does the agent’s next answer change without anyone editing a prompt?
- Can two people with different clearances ask the same model the same question and each get a correct answer?
- What happens when two facts a user may see separately combine into one they may not?
- Show me the log of the last query, and the rule that allowed it.
- Who is named on each access: the person, or the agent’s service account?
A vendor whose answers point to rights held outside the model has built something a regulated organisation can defend.
Monarch enforces security and governance down to the individual field, inside your infrastructure, under your accounts and your keys. See it on your data.