Infrastructure Access Should Not Mean Data Access
TL;DR
- Most software stacks treat infrastructure access as if it includes data access. Application servers, queues, logs, support tools, and now AI agents all sit downstream of a plaintext custody point that nobody chose to make.
- Cloud KMS, RBAC, and SOC 2 controls reduce blast radius, but they don't change the ownership model. Plaintext still lives where the infrastructure runs.
- ASTIS draws the boundary one layer up. The architecture separates four functions — storage, encryption, access control, and audit — into independent trust boundaries. One breach of one boundary doesn't compromise the others. Built on NIST/IETF-standard primitives. Edge services architecturally cannot decrypt; full architecture available for evaluation under NDA; third-party audit on the 2026 roadmap.
- This is the principle that runs through every product surface: PWA Mail and Calendar, the API Gateway, BYOK and HYOK custody, MCP for AI agents.
- Reading order for the rest of the series: Mail/Calendar [Part 2], API Gateway [Part 3], AI/MCP [Part 4], Platform thesis [Part 6].
What does "infrastructure access ≠ data access" actually mean?
Most security architectures collapse two questions that should never be one:
- Who can run a process?
- Who can read the data inside it?
These are different questions. Most stacks answer them with the same answer.
A team builds a service. The service needs a database, a queue, an analytics export, a support tool, and now an internal AI feature. Each of those needs identity, role, and audit. So the team adds RBAC, key vault, SOC 2 controls, and a quarterly access review.
Then they tell their largest customer's CISO: "We have controls."
The CISO replies: "Controls reduce risk. They don't remove plaintext from your infrastructure."
That CISO is correct. Controls govern who can act, not what plaintext exists where. As long as plaintext lives on infrastructure your team operates, every operational role with infrastructure access has a path to it. The path may be policy-restricted. It may be audit-logged. It is still a path.
This is the architectural mistake I'm starting this technical series with. In the posts that follow, I'll trace how it shows up across email, calendar data, API payloads, and AI workflows — and why ASTIS is built around a different boundary:
Infrastructure can run the process, but it should not automatically own the data.
Why is this happening in 2026 specifically?
Three things compound:
Stacks are wider. A typical B2B SaaS in 2026 often runs dozens of services, multiple data stores, analytics pipelines, internal AI features, support tooling, and external observability. Plaintext spreads not because anyone chose to spread it, but because every system asks for the easiest version of the data.
Regulators got specific. NIS2 Article 21(2)(h) requires "policies and procedures regarding the use of cryptography and, where appropriate, encryption." DORA and its ICT-risk-management RTS go further: financial entities need documented encryption and cryptographic-control policies, including lifecycle rules for cryptographic keys. "We use cloud KMS" is no longer the whole answer an auditor asks for.
AI agents arrived as a new access path. Once an agent can call tools, query APIs, read documents, and trigger workflows, it joins the infrastructure layer. The integration model that ships fastest — give the agent the data and let it work — is also the one that maximizes plaintext exposure.
The default of "infrastructure can see data" was already wrong in 2020. With NIS2 in force and AI agents on every CTO roadmap, it's now a liability.
Four questions to ask any vendor in your security stack
Comparing vendors directly is one way to evaluate. A more durable approach is to apply the same four questions to any vendor that touches encryption keys, customer data, or audit logs — managed cloud KMS, data vault, tokenization platform, secrets manager, hardware HSM, trust layer. The framework outlives any specific vendor and reuses across procurement cycles.
1. Who controls storage of customer ciphertext? If the vendor stores it on their infrastructure, customer data has moved into their trust domain. If storage stays with the customer (their database, object store, on-prem cluster) and the vendor only proxies opaque blobs, the storage boundary stays separate.
2. Who controls the encryption keys? Provider-managed keys mean provider-mediated decryption. Customer-managed keys with a single custodian still leave that custodian with full decrypt capability. Customer-managed keys with split custodianship (vendor-held share + customer-held share, both required) is structural separation — neither party can decrypt alone.
3. Who controls access decisions? If the same trust domain that holds keys also makes access calls, those are co-resident — one operational boundary doing two jobs. Access control on a separate tier with no cryptographic keys is structural separation.
4. Who controls the audit log? If the same vendor that performs encryption also writes the audit log on the same infrastructure, retroactive modification is theoretically possible. Tamper-evident audit needs operational separation: hash-chained events, periodic external time-stamping, and signing of security-severity events on a key the encryption tier doesn't hold.
Apply these four questions to any vendor on your shortlist. The patterns emerge quickly. The four-boundary architecture is what distinguishes a cryptographic trust layer from an adjacent product (managed KMS, vault, secrets manager, HSM) — same primitives often, different architectural composition.
Consider what happens when one of these boundaries is compromised — a misconfigured component, a stolen credential, an insider mistake, an attacker reaching the wrong tier. If storage, encryption, access, and audit are co-resident on a single trust domain, that single foothold reaches all four. The breach surface equals the operational boundary; the operational boundary equals the customer-data boundary. If the four functions live on four independent boundaries, the same compromise reaches one. Storage stays ciphertext at the customer side; keys stay in a separate custodian; access decisions stay in a tier with no cryptographic material; audit stays tamper-evident in a separate service. Architectural separation does the work that policy controls and operational discipline cannot.
ASTIS architects all four functions on independent trust boundaries by construction. The full architecture is available for evaluation under standard NDA today; third-party audit is on the 2026 roadmap.
What's the alternative? — Sealed envelopes
The architectural answer is simple to state and hard to retrofit:
The edge proxies opaque blobs. The keys that decrypt them live somewhere the edge cannot reach.
For ASTIS, "somewhere the edge cannot reach" means one of two things:
- CVS (CryptoVault Service) — a separate trust domain inside ASTIS, isolated from the main API gateway by independent SQL role + service boundary. Even an ASTIS engineer with full edge access cannot pull customer plaintext.
- HYOK pod — for ASTIS CVS Hybrid customers, the customer hosts their own CVS pod on their cloud or on-prem infrastructure. ASTIS coordinates routing but never touches key material.
The architecture is built on standard cryptographic primitives — PGP (RFC 4880), EdDSA (RFC 8032), FF1 (NIST SP 800-38G) — composed under a sealed envelope construction. The claim "ASTIS edge cannot decrypt" is a structural property of where keys live (CVS or HYOK pod), not a property of code we ask you to trust. Full architecture specifications are available for evaluation under standard NDA today; third-party audit is on the 2026 roadmap.
The three layers stay isolated at the credential level too. A service that encrypts holds an API key scoped to capsules:upload. A service that decrypts holds a separate API key scoped to envelopes:unwrap, bound to its own org identity. Compromising one does not open the other — and neither key reaches across tenant boundaries. This is a CQRS-style separation at the access-rights layer, not a policy document.
That distinction — math over policy — is the load-bearing principle. Every product in the ASTIS portfolio inherits from it.
Definitions
| Term | Meaning |
|---|---|
| Trust layer | The cryptographic infrastructure between customer applications and cloud storage designed to provide zero-knowledge edge access. |
| Sealed envelope | A PGP-encrypted blob that the edge proxies but cannot decrypt; only the org's private key (in CVS or HYOK pod) can open it. |
| Zero-knowledge by construction | The architectural property that edge services cannot decrypt, vs. policy-based "we promise we don't." |
| BYOK | Bring Your Own Key — customer-generated key material, sealed in ASTIS-managed CVS. |
| HYOK | Hold Your Own Key — customer hosts their own CVS pod; ASTIS never touches key material. |
| Edge service | Any ASTIS-operated component on the request path: api-gateway, WKD, audit-service. None can decrypt customer plaintext under sealed envelope architecture. |
Q&A — what readers actually ask
Q: Don't managed cloud key services already give us encryption?
Managed cloud key services give you encrypt/decrypt operations and key lifecycle. Standard managed keys are generated and protected inside the provider's HSMs; external-key modes exist for workloads where keys must remain in a customer-controlled key manager. ASTIS sits one layer above that question: edge services architecturally cannot decrypt customer content, even with full infrastructure access. Managed key services are key-management plumbing; ASTIS is the plaintext boundary above them. Many customers use both.
Q: Why not build sealed envelopes in-house?
6–12 months of engineering, ongoing maintenance, and crypto bugs that are catastrophic and hard to audit. ASTIS reduces the need to build and maintain this crypto-infrastructure in-house and produces audit-ready evidence. Primitives are NIST-standard (PGP RFC 4880, EdDSA RFC 8032, FF1 NIST SP 800-38G), so there's no algorithmic lock-in — you keep the option to migrate later.
Q: Where does plaintext exist in an ASTIS architecture?
At the customer's client (PWA Mail, the API SDK call site, the integrating application) and inside the customer's HYOK pod or CVS where the org private key lives. Nowhere else in the request path. No ASTIS-operated edge service can decrypt.
Q: What about AI agents reading customer data through MCP?
Same principle, applied to a new surface. Agents can call ASTIS APIs through MCP with per-operation scoped permissions — they receive tokens or signed envelopes, never raw plaintext. Each agent action is a named, audited operation rather than standing data access.
Q: How do I verify the math?
Two ways today. First, the building blocks are public standards: PGP (RFC 4880), EdDSA (RFC 8032), FF1 (NIST SP 800-38G), SHA-256 (FIPS 180-4) — no custom crypto, every primitive is documented and peer-reviewed. Second, full architecture specifications are available for evaluation under standard NDA. Third-party audit is on the 2026 roadmap. If anything in the design fails inspection, the claim is wrong and we want to hear about it.
How ASTIS maps onto the four boundaries
| Function | Where it lives in ASTIS | What that delivers |
|---|---|---|
| Storage | Customer-controlled (database, object store, on-prem cluster) | ASTIS edge proxies opaque sealed envelopes; the storage tier never holds plaintext on ASTIS infrastructure |
| Encryption | CryptoVault Service (managed BYOK) or customer-hosted CVS pod (HYOK); split custodianship of the encryption pepper share | Both vendor-held and customer-held shares are required to decrypt; ASTIS alone cannot decrypt |
| Access control | API gateway tier — holds API keys and scoped permissions; holds no cryptographic keys | A breach of the gateway tier cannot extract plaintext; gateway and key tier are different operational boundaries |
| Audit | Separate audit-service microservice; hash-chained per-organization events; daily TSA anchors; security-severity events Ed25519-signed | Retroactive modification is detectable; security events cannot be silently dropped |
Apply the four questions from the previous section to your current vendor stack. Then apply them to ASTIS. Architectural separation either holds across all four — or it doesn't. Math, not policy.
Design Partner Program
ASTIS is currently selecting design partners in EU regulated sectors — NIS2 essential entities, DORA-regulated financials, BaFin-supervised institutions, healthcare networks under EHDS, and law firms with cross-border client confidentiality obligations.
Design partner terms:
- Free 12 months on the platform tier matching the deployment
- Founder direct access during integration
- Architecture review under standard NDA
- Co-authored case study on completion (with permission, redaction at customer discretion)
Limited slots. The selection criterion is pattern depth: organizations whose four-boundary question maps cleanly onto the architecture, whose audit posture benefits from documented separation, and whose security review process can publish findings (or whose privacy posture allows redacted publication).
If your organization fits this profile, the form below is the entry point.
How this connects
This is the first post in the ASTIS series. It establishes the principle. The posts that follow apply it across surfaces:
- Part 2 (Mail + Calendar): the principle in daily communication. The provider should deliver the message without owning the content.
- Part 3 (API Gateway): the principle in application infrastructure. The API layer is where the plaintext boundary should be drawn.
- Part 4 (AI / MCP): the principle for AI agents. Scoped crypto access instead of unrestricted plaintext.
- Part 6 (Platform thesis): how the four surfaces stitch into one trust layer.
If you came in mid-series, this post is the foundation. Everything that follows is anchored here.