The setting

An agent wants to help you book a restaurant. It needs to know your dietary constraints. The naive thing is to give the agent broad read access to "preferences". The safe thing is to give it a one-shot, purpose-bound query that returns just the dietary preferences relevant to the task. That is what the GeraMind query layer tries to express cleanly.

The request shape

POST /v1/query
{
  "scope": ["preferences.dietary"],
  "purpose": "book-restaurant-tonight-london",
  "cap": { "facts": 10 },
  "expiry": "2026-04-21T22:00:00Z",
  "audience": { "agent_instance_id": "claude-desktop-device-7a2f" }
}

Each field is load-bearing. scope restricts the categories. purpose is a free-text declaration that binds the consent — if an agent later tries to reuse the same token for a different purpose, the vault refuses. cap bounds the volume of facts returned. expiry is short — typically minutes, not days. audience ties the token to a specific agent instance.

The consent flow

The first time an agent constructs a query of a given shape for a given user, the vault emits a consent challenge to the user. The user sees a single card: "Claude on your iPhone is asking for dietary preferences to book a restaurant tonight." One tap approves; the approval is bound to (scope × purpose × agent instance) and valid for the expiry.

Subsequent queries of the exact same (scope × purpose × agent instance) shape within the same day do not re-prompt. New combinations do.

The response shape

{
  "results": [
    { "key": "dietary.vegetarian", "value": true, "confidence": "high" },
    { "key": "dietary.allergens", "value": ["nuts"], "confidence": "high" },
    { "key": "dietary.preferences", "value": ["italian", "japanese"], "confidence": "medium" }
  ],
  "receipt": {
    "signed_at": "2026-04-21T19:15:00Z",
    "signer": "geramind",
    "signature": "..."
  }
}

The vault returns only the facts relevant to the purpose. It does not leak the full preference tree. The signed receipt is retained by both the agent and the vault so audit is reconciliable later.

Why purpose binding

Prompt-injection risk: a malicious page persuades your agent to use its existing consent token for something else. Purpose binding makes this fail closed. The token is "allowed to ask preferences relevant to restaurant tonight", not "allowed to query preferences forever". If the purpose changes, a new consent flow is required.

Why minimisation at the query layer

The classical pattern is to give agents broad reads and trust them to use only what they need. Agents are fine; but their hosting environments aren’t trustworthy. The browser sidebar agent that has full preferences in memory is a larger attack surface than one that only has three facts. Minimisation defends against agents that get compromised, not just agents that are malicious.

Why audit to the user

Every read is written to an append-only audit log the user can view through a user-held key. Operators can see aggregate counts; they cannot see content. This is not "your data, our dashboard" — it is "your data, your audit".

Sensitive tiers

Health data, documents, financial context get a separate tier with stricter defaults: shorter expiries, per-query prompts required (no same-day caching of consent), stricter audience binding. The user can soften these defaults, but only intentionally.

What this doesn’t solve

Agents can still be careless with what they put into their own prompt context after receiving a minimised response. The vault returns only three facts; where those three facts go next is outside our protocol.
If the user approves an excessively broad purpose, the downstream agent behaviour is limited only by its own safety behaviour.
Cross-vault query composition (for households sharing a vault) is not in v0. It is in the roadmap.

What we’re inviting comment on

The purpose-binding string shape. Whether expiries should be hard wall-clock or more like rolling semantics. Whether "agent instance" is the right grain. Whether sensitive-tier defaults should be per-category or per-data-sensitivity-score.

How a Consent-Scoped Query Works in GeraMind (Design Sketch)