Agent-Safe Reads (Read-Time Processing)

Keep raw data at rest. Let AI agents read only the safe projection — Maskura scrubs PII and encrypts on the way out, not on the way in.

The problem

Write-time processing is table stakes: your app PUTs through Maskura and PII is cleaned before storage. But agents often need to read existing datasets — buckets written by other systems, exports, or raw collections. Today the industry answer is a second cleaned copy, which drifts out of sync and doubles storage.

Maskura does the inverse: the object at rest stays raw. Every read runs the workspace's resolved read pipeline — redacting emails, cards, SSNs, and encrypting fields before the agent ever sees them. There is no client-elected mode: an agent cannot ask for raw bytes, and a read the pipeline cannot fully serve is denied rather than passed through.

How it works

  1. Your app writes raw objects (via Maskura's write path, your own S3 client, or a pre-existing bucket).
  2. An AI agent GETs the object through Maskura — nothing else is required.
  3. Maskura fetches the raw bytes, runs the PII/encryption pipeline, and returns the scrubbed result.
  4. The underlying object is unchanged — your app keeps full-fidelity data; the agent gets a safe projection.

Need raw reads for a bucket (bulk exports, media)? Assign that scope an explicit passthrough pipeline — a deliberate, audited policy decision in the same place every other pipeline is assigned, never a header the agent can send.

Example

# A read through Maskura — the assigned pipeline runs on the way out
curl https://api.maskura.dev/customers/customer-1.json \
  -H "x-maskura-access-key: s4_..." \
  -H "x-maskura-secret-key: s4s_..."
# → {"email":"[REDACTED_EMAIL]","card":"[REDACTED_CARD]","note":"hi"}

Via MCP

The public maskura-mcp stdio server's maskura_get_object tool applies the resolved read pipeline to every read — the process parameter is retained for compatibility and does not change what is served:

// "Read customers/export.json with the configured read pipeline"
maskura_get_object(bucket="customers", key="export.json")

Joinable reads (stable encryption)

Sometimes the agent doesn't just need safe data — it needs to join it (merge on a shared key, dedupe, or pivot). Redaction destroys that: every email becomes [REDACTED_EMAIL], so everything joins to everything. Envelope encryption (randomized AES-GCM) does too.

For joinable output, configure stable-encrypt before any redactor that would replace the join field, then set x-maskura-stable-fields on the read. The header supplies field names to the plugin; it does not reorder the pipeline or automatically bypass redaction. With that ordering, stable-encrypt applies deterministic AES-SIV, so the same value yields the same ciphertext without exposing plaintext.

# Agent joins two datasets on email, without seeing any email
curl https://api.maskura.dev/customers/c1.json \
  -H "x-maskura-access-key: s4_..." \
  -H "x-maskura-secret-key: s4s_..." \
  -H "x-maskura-stable-fields: email"
# → {"email":"ZuXfsc392EIpZaxcMJSPd1NoYfhadX7aR6+umdNkHv4=","note":"first"}

curl https://api.maskura.dev/customers/c2.json \
  ... -H "x-maskura-stable-fields: email"
# → {"email":"ZuXfsc392EIpZaxcMJSPd1NoYfhadX7aR6+umdNkHv4=","note":"second"}
# the email ciphertext is identical -> joinable

The ciphertext is deterministic for the configured stable key, so reads using the same configuration agree. This is the joinable + safe pattern when the pipeline is ordered as described above.

Why this matters

Limits and streaming