# Permissions are not prompt instructions.

Keep identity and access in the host application. Filter before generation, limit tools, recheck actions and prevent token or tenant leakage.

Version 1.0 · 2026-07-29 · 9 min

## Short answer

A prompt can explain policy, but it cannot enforce access. The host application must resolve identity, calculate effective permissions, filter knowledge and live data before generation, limit the eligible tools and check every action again at execution. Tokens need the correct audience and must not be passed through to unrelated services. The assistant should know whether a result is empty, denied or unavailable without receiving restricted content.

## Key points

- Authorisation is a deterministic product responsibility.
- The model should receive an already-scoped context and tool catalogue.
- Every consequential call is revalidated by the host at execution time.

## Natural-language rules are not a security boundary

Instructions such as “do not reveal records from another tenant” describe an intention. They do not prevent retrieved content, a compromised tool result or a prompt injection from steering the model toward restricted data.

The safer design removes forbidden data and operations before model selection. The model can explain that access is unavailable, but it does not need the protected content or the credential that could retrieve it.

## A monotone security pipeline

Probabilistic stages may rank or narrow choices. They must never widen a deterministic boundary.

### 1. Authenticate

Use the host session or a properly scoped delegated token. Validate issuer, audience, expiry and resource.

### 2. Authorise

Calculate effective read and write permissions for the tenant, site, record and operation.

### 3. Filter before retrieval

Apply access metadata before candidate text is loaded into model context. Do not retrieve broadly and hide later.

### 4. Reduce eligible tools

Remove unavailable or forbidden operations before semantic routing. Keep credentials and downstream tokens out of prompts and logs.

### 5. Validate every call

Check tool, arguments, scope, current state and permission at the server boundary. Reject stale or cross-tenant identifiers.

### 6. Trace without leaking

Record decisions, identifiers and result classes with redaction. Avoid copying tokens, full prompts or unnecessary personal data.

## Examples

### Different roles, same question

The customer context never contains approval tools. The operator can prepare a correction. The administrator sees the review path only when the host grants it.

### Cross-tenant identifier

A record ID sent by the browser is resolved inside the current tenant. A valid identifier from another tenant returns denied, not data.

### MCP resource access

The MCP server validates that the token was issued for its own resource and does not pass that token through to an upstream API.

## Common failure modes

- Writing permissions as system-prompt instructions.
- Retrieving restricted chunks and asking the model not to mention them.
- Accepting browser-provided tenant or role claims.
- Passing one broad token through several downstream services.
- Logging prompts, tool arguments or results without a redaction policy.

## Checklist

1. Identity comes from an authenticated host session.
2. Resource and audience validation are explicit.
3. Access filters run before retrieval and generation.
4. Tool eligibility cannot be widened by semantic routing.
5. Every action rechecks permission and current state.
6. Empty and denied are distinct response classes.
7. Logs exclude secrets and minimise personal data.
8. Prompt injection and cross-tenant tests are part of release acceptance.

## Limitations

- This architecture reduces exposure but does not replace a full threat model.
- MCP standardises protocol behaviour; it does not make every server trustworthy.
- Security claims still depend on the implementation, deployment and operating process.

## Sources

1. [Model Context Protocol specification](https://modelcontextprotocol.io/specification/2025-11-25) — MCP maintainers, 2025-11-25; type: standard.
2. [MCP Security Best Practices](https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices) — MCP maintainers, 2026; type: official-documentation.
3. [AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks](https://openreview.net/forum?id=m1YYAQjO3w) — Debenedetti et al., 2025; type: research.
4. [Adversarial Machine Learning: A Taxonomy and Terminology](https://www.nist.gov/publications/adversarial-machine-learning-taxonomy-and-terminology-attacks-and-mitigations-0) — NIST, 2025; type: standard.
5. [OWASP Top 10 for LLM Applications 2025](https://owasp.org/www-project-top-10-for-large-language-model-applications/assets/PDF/OWASP-Top-10-for-LLMs-v2025.pdf) — OWASP, 2025; type: standard.

## Practical questions

### Can a prompt still contain policy guidance?

Yes, for explanation and behaviour. Enforcement must remain outside the model in deterministic controls.

### Should the assistant reveal that access was denied?

Only at the level appropriate for the product. It can state that information is unavailable without confirming the existence of a protected record.

### Does self-hosting solve the access problem?

No. Hosting location and authorisation are separate. A self-hosted model can still receive over-broad data or credentials.

---

Canonical: https://scoperail.fokalabs.io/en/guides/permissions-are-not-prompts
Author: Ramzi Laieb, FokaLabs