PCI scope & privacy
One rule per data class, applied at every boundary
The table below is the rule set the build is written against. It is a design contract, not a
certification: the columns say what each plane is permitted to see, and the prohibitions are absolute rather than
consent-dependent.
Data-handling boundaries
| Data class | Agent / model context | MCP server | Storage |
Sensitive authentication data CVV/CVC, PIN and PIN blocks, full track data |
Never | Never |
Never after authorisation |
Raw payment credentials full PAN, bank account number |
Never | Avoided entirely |
Pinch tokenisation boundary only |
Security credentials Pinch secret key, OAuth tokens, API keys |
Never | In-memory retrieval only, request-scoped |
Secrets manager / KMS |
| Tokenised payment references |
Permitted | Permitted |
Encrypted |
Display-safe payment data brand, source type, last four |
Permitted when necessary | Permitted |
Limited retention |
Personal information name, email, address, phone, IP |
Redacted or pseudonymised | Only when operationally necessary |
Purpose-limited |
| Transaction information |
Permitted with a pseudonymous customer ID | Permitted |
Financial retention policy |
Unstructured content prompts, uploaded invoices, OCR, generated code |
Pipeline — redaction scan before use |
Pipeline — redaction scan in both directions |
No raw prompt retention |
What the standard says. PCI DSS prohibits storing CVV/CVC, PIN and PIN blocks and related
sensitive authentication data after authorisation, even when encrypted. A customer cannot consent around
that prohibition, so it is enforced as an absence of fields rather than as a policy.
Redaction path — pipeline
What exists today. The absence of card and bank fields in every tool
schema, hosted-only capture of payment sources, request-scoped credentials, hashed tenant tags in audit lines with no
parameters or results logged, and a 200 kB cap on tool output. There is no content-classification layer in this
release: the boundary is currently enforced by what the schemas cannot accept, not by scanning.
What is planned. Two redaction passes on the way out and one on the way back, with three
treatments: remove (CVV, full PAN, passwords, API secrets), tokenise (payer identity, payment source,
bank-account reference) and mask (Visa •••• 4242, payer_7F21, $99 AUD).
Model context will carry session-scoped aliases such as CUSTOMER_01, with the alias-to-identity map
held in a separate encrypted vault the model cannot reach. Detection is to cover structured tool arguments, free text,
uploaded documents, OCR output, generated code, model outputs, error messages, traces, audit logs and support
exports. Where classification fails, or a probable card number appears where one should not exist, the request
fails closed.
Australian privacy obligations
| Obligation | What applies | Hackathon build today | Pipeline |
| APP 1 — open and transparent management |
A clearly expressed, up-to-date privacy policy covering how personal information is handled |
Data-handling rules published here and in SECURITY.md |
Product privacy policy and collection notice per deployed workspace |
| APP 3 — collection of solicited personal information |
Collect only what is reasonably necessary for a function or activity |
Synthetic customers only; tools request name, email and amount — no card or bank fields |
Field-level necessity review per tool before live operation |
| APP 11 — security of personal information |
Reasonable steps to protect information, and to destroy or de-identify it when no longer needed |
TLS in transit, no credentials at rest on the server, hashed tenant tags in logs, bounded outputs |
Retention schedules with automated destruction and de-identification jobs |
| Personal information is broader than names |
Transaction history, IP addresses, device identifiers, location and combinations of otherwise harmless
data may identify someone |
Pseudonymous customer IDs in model context; audit lines carry a hashed tenant tag, not a merchant ID |
Re-identification risk assessment across the combined telemetry set |
| Consent and purpose limitation |
Specific consent for a stated purpose, rather than a broad “AI use” consent |
Not applicable — no real personal information is processed in the sandbox build |
Per-purpose consent capture, and model-provider and cross-border disclosure review |
| Access and correction |
Individuals may request access to, and correction of, their personal information |
Payer records are readable and correctable through Pinch |
Documented access and correction workflow with response timeframes |
| Notifiable Data Breaches |
Assess suspected eligible breaches and notify the OAIC and affected individuals |
Per-call audit logging provides the evidence trail for assessment |
Written NDB response plan, with SIEM alerting on failed-validation and high-frequency patterns |
Automated-decision transparency commences 10 December 2026 |
Privacy policies must disclose automated decisions that use personal information where those decisions
significantly affect an individual's rights or interests |
Remi makes no such decision: it drafts, previews and explains — a human approves every write |
Disclosure statement, plus a standing prohibition on creditworthiness, hardship and KYC-override
decisions by the agent |
What the agent may and may not do
| The agent may | The agent may not do autonomously |
| Interpret commercial requirements; recommend a Pinch pattern; generate a billing blueprint; explain
fees and schedules; create drafts and previews; simulate failures; identify reconciliation
differences |
Charge a customer; increase an amount; change the receiving merchant; refund a settled payment; create
or modify payout details; retry indefinitely; make creditworthiness or financial-hardship decisions;
override compliance or KYC status |
Financial execution stays deterministic, bounded and reviewable. The MCP server is a constrained
financial control plane, not a generic proxy: there is deliberately no pinch.call_api(method, endpoint,
body) tool, because a generic passthrough would let prompt injection turn the agent into an unrestricted
API client.