A wealth advisor reads household composition, AUM, account structure, and the running conversation with the family. Compliance holds the basis for every restriction or flag. The internal agents your firm builds to support the advisor read a wider slice: restriction outcomes, hashed match identifiers, KYC tier. Each role gets the keys its job needs. Every read leaves a signed trail.
The record is written once. The advisor app, the agent runtime, and the compliance auditor open it through their own keys. The fields each role can decrypt are baked into the record at the moment it is sealed. Access lives in one place: the keys.
Household composition, AUM, accounts, conversation history, restriction badges. Enough to do the job. The badge says hold; it does not say why.
Restriction outcomes, hashed identifiers for cross-checks, conversation context, KYC tier. Enough to answer “is this trade allowed?” without ever decrypting the underlying watchlist or the basis for the flag.
Everything, including the basis fields nobody else can read. Plus the policy hash that was in force the moment each event was logged. The trail is signed end-to-end.
hold, review, or clear. The list, the counter-party, and the date that triggered the flag stay in the basis layer. The advisor UI renders the badge. Compliance holds the key that opens the why. The audit log captures every step. Every advisor. Every agent run. Every record.
This is not access-control bolted on after the fact. It is the shape of the record itself. New advisors and new agents inherit the policy by joining the audience; deprovisioned ones lose access by rotation. There is no “forgot to update the rule” failure mode because there is no rule to update.
TN ships an OpenTelemetry adapter and handlers for the common log shippers. Your SIEM, your dashboards, and your alerts keep working. Sealed fields look like opaque ciphertext to them. There is nothing left to redact downstream.
TN ships an OpenTelemetry adapter and handlers for most log shippers. Your SIEM, your dashboards, and your alerts keep working. Sealed fields look like opaque ciphertext to them. There is nothing left to redact downstream.
And critically: contractors and consultants on-site to build your dashboards can't see sensitive data while they work. They get the fields they're granted, nothing else.
Logs tell you everything: from "Hello World" to "What did the user do before this error?" The risk is that they also tell anyone with read access to the log shipper. We took a popular e-commerce platform, ran its tests, and asked an LLM to find every place customer data could leak.
Saleor is one of the most widely deployed open-source e-commerce platforms in the world and we here are big fans of their coding practices. Out of love, we cloned their project and ran its standard test suite to see exactly what comes out of the core payment and order code when it is exercised. We did not write a single line of test code.
Then we gave the LLM one instruction:
We did not tell it which files to look in. We did not tell it which fields to protect. We did not write a list of PII fields or a data classification policy.
logger.info() as a format argument# saleor/payment/tasks.py for transaction_item, event in transactions_with_cancel_request_events: logger.info( "Releasing funds for transaction %s - canceling", transaction_item.token, # <-- tok_visa_4242 in every log shipper extra={"transactionId": graphene.Node.to_global_id(...)} ) except PaymentError as e: logger.warning( "Unable to cancel transaction %s. %s", transaction_item.token, # same token, now in a warning str(e), )
%s format argument. It lands verbatim in Datadog, Splunk, CloudWatch, or wherever you ship logs. No exception needed. Every normal operation leaks it.# agent added one tn.info() call per operation # groups it chose: finance (amounts/tokens), pii (customer) # order_id and gateway stay in the clear for tracing tn.info("payment.process.called", gateway=payment.gateway, # default group, visible order_id=str(payment.order_id), # default group, visible amount=str(payment.total), # finance group, sealed currency=payment.currency, # finance group, sealed payment_token=str(payment.token) # finance group, sealed )
You and any agent type assistants you have define groups based on who needs to read which fields in your system. A group is just a name and an encryption key for everyon one who needs to encrypt that group. You can have two or twenty or 200.
For Saleor, the agent chose two. A more complex system might also want fraud for risk scores and device fingerprints, legal for dispute notes, support for contact history. The same pattern scales to any number of audiences.
customer_email, billing_address across the five order lifecycle events: created, confirmed, cancelled, payment captured, fulfillment fulfilled.
The agent placed these here because compliance, legal, and support need them. Engineers debugging a failed webhook do not.
payment_token, third parties, comments about bugs You don't want these in your log aggregator. You don't want them in your SIEM. You don't want them in the hands of an attacker that got read access to your logs. But you do need to record them somewhere for debugging and incident response.
Finance reconciles every transaction without reading customer names. Engineers trace orders without reading amounts.
This is real output from the benchmark run. Every entry in the log is the same sealed record. What you can open depends entirely on which key you hold.
Claude Code, Cursor, Copilot, Windsurf, Aider. We maintain a skill and a prompt library for each one. Point your agent at your payment module, your auth flow, your event pipeline. Ask it to do what we did here.
The agents page has everything: the prompts, the AGENT.md reference the LLM reads, and the install instructions for each tool.
See the agent prompts