API Trust Layer for Sensitive Data: Controlling Plaintext Across Product Flows
TL;DR
Most modern software systems do not fail because encryption is absent. They fail because plaintext appears in too many places.
Sensitive data can enter through an API — or be created by the product itself — and then spread across services, logs, queues, analytics, support tools, exports and AI workflows.
ASTIS API Platform is the second ASTIS product surface after Mail/Calendar: an integration layer for SaaS, on-prem and hybrid software teams that need payload-level trust boundaries inside product flows.
The goal is not to replace API gateways, KMS, SIEM or DLP. The goal is to control where sensitive fields are encrypted, tokenized, masked, signed, revealed and audited.
For enterprise buyers, the stronger question is no longer "do you encrypt data?". It is: where does plaintext live, who can reveal it, and what evidence proves it?
Why this post
In many software products, sensitive data does not stay where architecture diagrams imply it should stay.
It may enter through an API. It may also be created by the product itself: a risk score, a legal summary, an insurance decision, a support note, a compliance report or an AI-generated output.
From there, plaintext can quietly spread into application services, logs, queues, background workers, analytics, support dashboards, exports and AI workflows.
That is the real trust-boundary problem.
Encryption at rest helps. TLS helps. KMS helps. DLP helps. But none of them automatically answer the more important architecture question:
Where does plaintext exist inside the product, and does every component that sees it actually need to see it?
W1 set the general principle: infrastructure access should not mean data access. W2 showed it applied to Mail/Calendar. W3 applies the same principle to product APIs and internal data flows.
ASTIS API Platform exists for a different model.
Sensitive fields should change shape at the point where the workflow requires control — whether that point is API ingress, application code, middleware, a sidecar, an internal service, an AI workflow or a controlled reveal operation.
Depending on the use case, the downstream system should receive an envelope, token, masked value, hash-only signature or signed object instead of raw sensitive data.
Plaintext reveal should be explicit, authorized and audited. Not a side effect of database access, queue access, log access, admin access or internal dashboard access.
Why this matters more right now
A few years ago, in less regulated or mid-market security reviews, an answer at the level of "encryption at rest, IAM, access logs, DPA" often passed as a baseline control. For regulated enterprise buyers it was never the full answer, but it frequently closed the first round of vendor review.
That's becoming less and less true. Three regulatory shifts are now driving the procurement question straight into the architecture itself:
- NIS2 — Article 21(2)(h). Raised the bar to policies and procedures for cryptography and encryption. Transposition deadline passed October 2024; essential and important entities now need a documented cryptographic policy with auditable operational evidence — and they're pulling that requirement into their supplier reviews.
- DORA — Articles 6–10. In application since 17 January 2025. ICT risk management, including cryptographic controls and third-party provider obligations, is now a practical procurement question for the financial sector and every vendor in its supply chain.
- GDPR — Article 32. Still the baseline. Appropriate technical and organisational measures — including encryption and pseudonymisation — read differently in 2026 than in 2018; reviewers now want architectural answers, not just "encryption at rest".
The US and Canada operate on different statutes — HIPAA Security Rule §164.312 for healthcare PHI, SOC 2 Type II Common Criteria (CC6.7) as a de facto B2B SaaS procurement standard, PCI DSS v4.0 for payment data, CCPA/CPRA "reasonable security" in California, NYDFS 23 NYCRR 500 for New York financial services, and PIPEDA plus Quebec Law 25 in Canada — but the architectural question they all return to is the same: where does plaintext live, who has the reveal path, what evidence proves it.
On top of regulation, AI agents are connecting to the same APIs that used to be read only by internal services — multiplying the access paths to customer data almost overnight.
Public incidents have also shifted buyer psychology. Storm-0558 showed that a weakness in the control plane or identity path can turn into customer data access. Midnight Blizzard in 2024 showed another variant of the same pattern: an identity/application access path can become a corporate email access path. For a CISO this isn't abstract cryptography. It's a question of blast radius — if infrastructure or an application path is compromised, does that automatically mean data access?
So buyers no longer ask only "do you encrypt?". They ask:
Where does plaintext exist, who has the reveal path, and what artifact proves it?
The Trust Boundary Belongs Inside the Product Flow
The boundary is not always a network edge.
In some workflows, it can sit at API ingress. In others, it belongs inside application code, middleware, a sidecar, a background worker, an AI pipeline or a controlled reveal service.
The important point is not where the HTTP request enters.
The important point is where plaintext is created, transformed, revealed, stored or passed downstream.
Security or compliance teams can correctly say: we need an audit trail, control of unwrap/reveal, documented cryptographic operations, less plaintext exposure.
But product engineering still has a practical question:
Which capability do I call, and where in the flow?
Policy doesn't change a payload. A checklist doesn't stop plaintext from landing in a queue. An architecture diagram doesn't create an audit event.
ASTIS API Platform turns these requirements into an integration layer:
- Sealed envelope / capsule flow: the client encrypts the payload or wraps the data key locally; ASTIS only stores or routes the encrypted capsule / sealed material and supports sealed unwrap without receiving the raw payload.
- FPE token flow: the client fetches the permitted sealed key share and performs FF1 locally; downstream receives a format-preserving token, not the raw value.
- Hash-only sign / verify: the client hashes the payload locally; ASTIS signs or verifies the hash without seeing the payload.
- BYOK / HYOK routing: the custody model can shift toward a customer-controlled key domain when the workload requires it.
- Audit evidence: sensitive operations automatically produce audit events; the client reads evidence rather than writing audit logs by hand.
On the API level this is a small surface area, not a new data store: capsule lifecycle, sealed envelope unwrap, FPE key material for customer-side FF1, hash-only sign/verify, BYOK/HYOK custody routing, and read-only audit evidence. Concrete endpoint paths, scope catalog and latency targets live in developer documentation and a technical brief — they're best consumed in their current versions, not embedded in a blog post.
In this model, ZK is not a marketing checkbox. It's a placement rule: plaintext should not pass through any component that does not explicitly need it if the workflow can be executed with a client-side wrap, token, mask, hash signature, sealed envelope or controlled reveal path.
The deployment model depends on the workload: managed API for a fast start, hybrid boundary for stricter custody requirements, HYOK where key material has to stay in a customer-controlled domain. Latency targets and SDK status are better walked through in a technical review, because they depend on data class, region and integration path.
The point isn't that an API endpoint is magical on its own. The point is placement: if a client-side wrap / FPE / hash-only signing / audit evidence flow sits after plaintext has already spread across the stack, the boundary is late.
How plaintext spreads — and what should change
In most teams this doesn't look like an obvious mistake. Nobody decides "let's scatter customer plaintext across all services". It happens through normal product decisions.
| Surface | Typical default | What an API trust boundary should give |
|---|---|---|
| API request | Full payload enters the application service | Sensitive fields change shape early: envelope, token, signed object |
| Generated records | Statements, scores, reports, approvals or summaries are created as raw plaintext | Created or stored directly as protected form where possible |
| Logs | Partial request/response fragments | Logs see token / envelope / masked value, not raw sensitive fields |
| Queue / workers | Full event payload | Workers receive only what the workflow actually needs |
| Support tooling | Raw customer fields | Masked view + explicit audited reveal for rare cases |
| Analytics | Operational copy in the warehouse | Aggregate / category / token instead of plaintext |
| AI workflow | Agent reads the API response | Scoped crypto operation instead of unrestricted raw data access |
| Security review | Manual explanation | Boundary map + audit evidence instead of a tour of the whole stack |
This is plaintext intentionality: plaintext exists only where the workflow truly needs it. Not because it accidentally turned out that way after the first API request, generated report or AI summary.
What changes after ASTIS API Platform is introduced
1. Sensitive fields change shape earlier. The team performs wrap, FPE or hashing locally when data enters or is created inside the product flow; the ASTIS API helps with key material, capsules, signatures, custody routing and audit evidence. The downstream stack receives the protected form by default.
Architecturally, the ASTIS edge is not the decrypt path. The API gateway, WKD and audit surface handle routing, public-key lookup, scope enforcement and evidence; key-vault operations live in a separate trust domain — CVS. In managed mode this is an ASTIS-operated CVS. In hybrid or HYOK mode the custody boundary can move closer to a customer-controlled domain.
Compromising the edge layer must not automatically equal plaintext access.
2. Reveal/unwrap becomes a separate operation. Plaintext is not the normal state of the downstream stack. If a raw value is genuinely required, that's an explicit operation: who, when, for what purpose, with what policy context.
3. Audit evidence is born together with the operation. Security review gets not just "we control this" but evidence: which capsule, unwrap, FPE key-fetch, sign/verify or custody operations took place, when, and in which workflow. For stronger audit requirements this can be shaped into a hash-chained evidence model described in a technical brief.
4. The application stack doesn't write its own crypto/control plane. The product team integrates primitives instead of building key lifecycle, reveal policy, token formats, signing and audit model itself, inside the very stack that should be constrained.
5. Enterprise buyers get a shorter answer. To "where does our plaintext live?" the team can show: creation or ingress point, protected form, allowed reveal paths, audit trail.
This is not a replacement for a traffic gateway, KMS, secrets manager, DLP or SIEM. It's a different layer: an application-layer trust boundary for customer data.
That is the category difference. ASTIS is not asking the buyer to trust one more plaintext-owning layer. It helps the product team move plaintext out of the application path while keeping business context in the customer's own systems as a protected form — envelope, FPE token, masked value or signed object. Reveal operations stay explicit, and evidence is generated when they happen.
Three product-flow examples
Customer profile with PII. Name, email, phone or national identifier should not automatically reach every downstream system. Some services need a token, some a masked value, some — an audited reveal.
Billing or payment identifiers. Downstream often needs a reference, last-four or a format-preserving token, not the raw value. This reduces exposure in jobs, exports and analytics.
AI feature over customer content. An agent or classifier shouldn't get unrestricted plaintext by default. Better to give it a scoped operation: classify a protected form, sign a hash, retrieve FPE-tokenized or masked context, or go through an audited reveal only where it's justified.
In all three cases the question isn't "encrypt or not". The question is: what shape of data should each component receive?
Where this is particularly useful
ASTIS API Platform fits best where the product already handles sensitive customer data, but the team doesn't want to build its own crypto/control/audit layer from scratch.
- DevTools and infrastructure SaaS: customer code, configs, logs, secrets-adjacent metadata, deployment data.
- MarTech and customer-data SaaS: contacts, segments, behavioral data, campaign data, support history.
- B2B SaaS for enterprise customers: documents, forms, CRM records, project data, customer-uploaded files.
- LegalTech and document workflows: client files, contracts, matter metadata, signed events.
- EdTech and collaboration tools: learner records, assessments, corporate training data, team content.
- AI products and copilots: prompts, retrieved context, customer documents, agent actions, generated summaries.
The strongest fit is when an enterprise prospect is already asking: "where is our data stored, who can read it, is there BYOK/HYOK, and what will you show in security review?"
How to start without rebuilding the whole stack
The worst way to introduce a trust boundary is to tell the team "rebuild everything".
The reasonable way is to start with one data class.
- Where is the field created or received?
- Which services actually need the raw value?
- Where is a token, envelope, masked view or signed event enough?
- Which reveal operations should be allowed?
- What audit artifact is needed for security review?
After that, the integration becomes a smaller task: not "encrypt everything", but place a boundary for a specific data class and specific workflows.
Q&A
Q: Is ASTIS API Platform an API gateway? A: Not exactly. It can integrate at a gateway point, but the core idea is broader: ASTIS API Platform is a payload-level trust layer for sensitive product flows. It can be invoked from application code, middleware, sidecars, services, workflows or gateway integration points. The goal is to control when sensitive data remains sealed, when it becomes a token or masked value, when it is signed, and when plaintext reveal is allowed and audited.
Q: How does this integrate with an existing Kong, AWS API Gateway or internal gateway? A: As a payload trust layer next to the traffic gateway. Routing/auth/rate-limit stay where they are. The sensitive operation is invoked from application code, middleware, a sidecar or a gateway integration point — depending on architecture and latency budget.
Q: How is this different from vault-based tokenization or a self-built solution? A: The question isn't the name of the category. The question is which component holds the reveal path, whether it's isolated from the application layer, and whether every reveal/detokenize/unwrap leaves audit evidence. In a vault-based model the original value usually has to be recoverable for legitimate detokenize. In a self-built model crypto, reveal logic and audit often live inside the very stack they should be constraining. ASTIS framing is different: the application stack uses the trust layer, but is not forced to become the owner of all crypto, custody, reveal policy and audit logic.
Q: Can it be self-hosted or hybrid? A: For workloads with strict custody requirements the model has to be discussed separately: managed API, hybrid boundary or HYOK. If the key material has to stay in a customer-controlled domain, that's not a marketing-copy decision; it's an architecture review.
Q: How do AI agents get access? A: Through scoped operations, not unrestricted raw data access. For MCP workloads this means runtime delegation through the MCP surface with opt-in scopes for unseal, tokenization, sign and verify; base MCP access by itself should not open a runtime crypto path. An agent can receive FPE-tokenized/masked context, invoke a hash-only signing or verify operation, or go through an explicit reveal/unseal path where policy allows it and the customer has explicitly accepted it.
Q: What about compliance evidence for NIS2 / DORA / GDPR? A: ASTIS API Platform helps gather technical evidence: a boundary map, allowed reveal paths, cryptographic operation events, an audit trail. It does not "close compliance" on its own; legal obligations, policies, incident process and auditor review remain on the organization's side.
Q: Can it reduce PCI scope? A: It can help, if the FPE/tokenization architecture, processes and evidence are validated within a QSA or security review. This is not an automatic promise — it's architectural input into a scope discussion.
Q: Where does plaintext live? A: In a healthy flow plaintext should exist in as few places as possible: where the client app or a trusted service creates it, and where the workflow genuinely requires a reveal. After the trust boundary, downstream should receive a protected form — envelope, FPE token, masked value or signed object. If the raw value is needed for support, billing, an AI workflow or an internal service, it should be a separate reveal/unwrap operation with an audit event, not a side effect of access to the database or queue.
Get in touch
The next generation of enterprise security reviews will not stop at asking whether data is encrypted.
They will ask sharper questions:
- Where does plaintext live?
- Who can reveal it?
- Can support, analytics, logs, AI workflows or internal services see raw sensitive data?
- Is every reveal explicit and audited?
- Can the customer choose BYOK, HYOK or tenant-controlled custody?
That is the problem ASTIS API Platform is designed to solve:
not just encryption, but plaintext control across the product stack.
Below: tell us which data class or data flow is most sensitive for you. We'll look at it and come back with where the boundary can be placed.
Or book a 30-minute conversation — no deck, no download, no document to download. One data flow, one boundary map.