Your AI Agent Is a New Access Path Into Sensitive Data. AZK Is the Boundary.
TL;DR
AI agents are becoming a new plaintext access path into sensitive data.
They read customer records, contracts, support tickets, logs, embeddings, and compliance documents.
The security question is no longer:
"Which LLM provider do you use?"
The question is:
What exactly does the agent see?
Who authorized it?
Can access be scoped per operation?
Can it be revoked?
What audit artifact proves it?
This is the boundary ASTIS calls AZK — Agentic Zero-Knowledge.
AI agent access should not mean plaintext access.
E2E/ZK protects the provider boundary: infrastructure access does not mean data access.
AZK adds the agent boundary: AI agents can participate in workflows, but plaintext access must be explicit, scoped, and auditable — not a default side-effect.
ASTIS MCP is the first ASTIS product layer for AZK.
It has two layers:
- Dev-time MCP — helps AI coding agents build ZK-clean integrations.
- Runtime MCP — gives production AI agents scoped crypto operations inside the customer's trust boundary.
This is not a launch note. Not "another MCP connector."
This is a new security category: how to integrate AI agents into sensitive data workflows without losing zero-knowledge posture.
Why this matters right now
W1 set the principle: infrastructure access should not mean data access. W2 applied it to Mail/Calendar. W3 extended it to product APIs. W4 — the new actor that emerged in 2026: AI agents entering sensitive data workflows.
In 2024–2025, AI agents were mostly a productivity layer.
In 2026, they're becoming an infrastructure layer.
They read data, call tools, run transforms, generate summaries, write into downstream systems, trigger workflows.
For an ordinary SaaS, this looks like velocity.
For a regulated SaaS, this looks different:
- the agent gained access to PII;
- the agent read PHI;
- the agent processed a privileged contract;
- the agent injected a customer record into LLM context;
- the agent called an external tool with a sensitive payload;
- the agent generated code that quietly sends plaintext into the wrong boundary.
The AI agent is no longer just a "feature."
It becomes a new actor in your trust model.
And that's where the compliance question begins.
GDPR, NIS2, SOC 2, HIPAA, PCI-DSS, and internal CISO review don't only ask:
"Do you have AI?"
They ask:
"What data does the AI system see?"
"Can it see plaintext?"
"Who granted that access?"
"Can the access be limited per operation?"
"Can it be revoked?"
"What exactly went to the LLM provider?"
"Where does the plaintext live?"
"What audit artifact proves it?"
If there is no architectural answer to these questions, the AI agent becomes an unmanaged data access path.
The trust boundary has changed
In classical cloud architecture, the security team looks at users, services, APIs, databases, queues, logs, third-party processors.
AI agents add one more boundary.
The agent can hold credentials.
The agent can read context.
The agent can call tools.
The agent can move data between systems.
The agent can do all of this autonomously, not as a one-shot API client.
So the old question — "does this service have API access?" — is no longer enough.
The new question:
What exactly does the agent see at the trust boundary?
If the agent sees raw plaintext everywhere it has technical access, that's not a zero-knowledge architecture. That's just API access with an AI layer on top.
ASTIS takes a different position:
An AI agent can be granted capability, but not automatically plaintext.
Access has to be:
- scoped;
- purpose-bound;
- auditable;
- revocable;
- limited to the operation;
- aligned with the customer's trust boundary.
That's AZK.
What AZK is
AZK — Agentic Zero-Knowledge.
It's not a new cryptographic primitive.
It's an architecture discipline for the AI-agent era.
E2E/ZK says:
Providers and infrastructure do not have plaintext by default.
AZK adds:
AI agents also do not have broad plaintext access by default.
So an AI agent can participate in a sensitive workflow, but its access to data has to be bound to a specific operation.
Not "the agent sees everything because it might need to think about it."
Instead:
- the agent can request decrypt only for a specific object;
- the agent can sign only a specific hash;
- the agent can tokenize a specific field;
- the agent can verify a signature without seeing plaintext;
- the agent can receive a result, but not raw key material;
- every action has a scope and an audit trail.
The short formula:
E2E/ZK protects the provider boundary.
AZK protects the agent boundary.
This is the framing we want to put on the table.
Not "MCP for encryption."
Not "AI connector to a KMS."
A control layer for AI agents entering sensitive data pipelines.
ASTIS MCP — the product layer for AZK
MCP has emerged as the natural protocol surface for AI agents.
Coding agents inside Cursor / Claude Code / Copilot speak to tools through MCP.
Production agents are increasingly receiving tool access through MCP-like interfaces.
So MCP is the right place to put a security boundary.
But just having an MCP server isn't enough.
A generic MCP connector can make the problem worse: giving the agent structured access to sensitive systems without a proper trust model.
ASTIS MCP exists for a different job:
Give AI agents access to cryptographic workflows in a way that keeps the plaintext boundary under control.
To do that, ASTIS MCP is split into two layers.
Layer 1: Dev-time MCP
Dev-time MCP is the AI-native integration layer.
Its user: a developer plus an AI coding agent inside an IDE.
Its job: help that AI agent generate integration code that doesn't break the zero-knowledge boundary.
The scenario is straightforward.
A developer types:
"Integrate ASTIS encryption-at-rest into my Express app for the
patient_recordstable."
Without ASTIS MCP, a generic AI agent might:
- invent an endpoint;
- pick the wrong scope;
- send plaintext into the API body;
- generate unsafe logging;
- mishandle the sealed envelope;
- hardcode a secret;
- produce an integration that looks logical but breaks the trust boundary.
With ASTIS MCP, the agent gets an ASTIS-specific contract:
- which endpoints actually exist;
- which scopes are required;
- which flow is ZK-clean;
- which integration template matches the use case;
- which patterns must be blocked;
- how to explain the flow for security review.
In this mode, MCP is not in the runtime data path.
It doesn't proxy production data.
It helps the AI coding agent write the right code path.
So Dev-time MCP isn't a classical SDK.
It's an AI-native SDK channel.
Layer 2: Runtime MCP
Runtime MCP is a different layer.
Its user: a production AI agent.
Its job: give that agent scoped crypto operations when it actually works inside the data pipeline.
For example:
- the agent can sign a hash without seeing document plaintext;
- the agent can verify a signature;
- the agent can tokenize a field;
- the agent can request decrypt only for a specific object, only inside the customer's trust boundary;
- the agent can receive a bounded result for a specific workflow, not broad database access.
The key rule:
Runtime MCP for sensitive plaintext flows must be customer-deployed.
Why?
Because if plaintext flows through ASTIS-hosted runtime, the zero-knowledge posture changes.
The canonical Runtime MCP lives where the customer controls the trust boundary: in their cluster, as a sidecar, inside the agent runtime, or in their infrastructure.
ASTIS provides the cryptographic control plane: scopes, policy, audit, key custody integration.
The customer-deployed Runtime MCP performs local, agent-facing operations where plaintext doesn't leave the customer boundary.
This isn't "the agent got the keys."
It's "the agent got a scoped capability."
Market thesis and product surface
ASTIS is putting AZK forward as a new security category — not a product feature.
The thesis is that AI agents need their own trust boundary, distinct from infrastructure access. ASTIS MCP is the first ASTIS product layer that implements it.
Dev-time MCP — the AI-native integration surface:
ASTIS MCP runs as a tool server for AI coding agents in Cursor, Claude Code, and Copilot. It exposes the ASTIS endpoint catalog, codegen templates with an AST-based ZK validator for TypeScript and JavaScript, and a threat-model tool for security review. The first catalogued integration paths cover TypeScript + Express (encryption-at-rest, sign, verify), Python + FastAPI (encryption-at-rest), and Go + Gin (encryption-at-rest). The integration matrix expands in controlled rollout, prioritised by customer demand.
Runtime MCP — the agentic control surface:
ASTIS MCP defines and enforces the mcp:runtime:* scope model in production: AI agents only get the crypto operations they were granted, with audit on every call. The canonical deployment for sensitive plaintext flows is customer-side — inside the customer's trust boundary — so that ASTIS provides the cryptographic control plane while plaintext never leaves the customer's infrastructure. This is the next product surface in the AZK rollout, and it gets its own post.
The framing we're putting on the table:
ASTIS MCP is the first ASTIS product layer for Agentic Zero-Knowledge. Dev-time MCP makes AI-generated integrations ZK-aware. Runtime MCP makes production agent access scoped and auditable inside the customer trust boundary.
AZK is the architectural conversation. ASTIS MCP is the first concrete implementation. The category is bigger than this product — and that's the point.
What ASTIS MCP checks at dev-time
The biggest risk in AI-generated crypto integration is code that looks right but breaks the trust boundary.
Example:
await fetch("/v1/envelopes/unwrap-key-sealed", {
method: "POST",
body: JSON.stringify({
plaintextB64: btoa(secret)
})
})
A generic AI agent can generate something like this.
It looks logical.
But it's a ZK violation: plaintext is being sent where a sealed envelope belongs.
ASTIS MCP's validator catches these patterns before the code reaches production.
For TypeScript / JavaScript, this is already an AST-based check, not just regex. It looks for ZK-breaking patterns: plaintext fields in request bodies, session pins at the top level, hardcoded prod keys, PGP private key handling, logging of request bodies.
This isn't formal verification.
But it's a practical AZK guardrail: AI-generated integrations get checked against ASTIS ZK invariants at codegen-time, not only after they fail in runtime.
Better an explicit finding than a hallucinated integration.
What ASTIS MCP controls at runtime
The runtime problem is different.
The agent isn't writing code anymore.
It's working with real data.
The question is:
How do you give an AI agent the ability to perform the crypto operation it needs, without turning it into an uncontrolled plaintext reader?
The AZK answer:
- don't grant broad plaintext access;
- grant a scoped operation instead;
- keep plaintext inside the customer boundary;
- record an audit artifact;
- make access revocable;
- separate key custody from agent execution.
Runtime MCP is the layer where this model becomes practical.
Not every agent needs decrypt.
Not every workflow needs plaintext.
Not every operation needs to flow through LLM context.
AZK forces the architecture to answer these questions before production, not during incident review.
Why this matters for compliance
Compliance doesn't block AI because "AI is bad."
Compliance blocks AI when nobody can explain the data boundary.
For an AI-agent workflow, you have to answer:
- which systems the agent can call;
- which data classes it can see;
- whether it sees plaintext or a protected representation;
- where plaintext physically exists;
- whether plaintext ends up at the LLM provider;
- who granted permission;
- on what scope;
- for what workflow;
- how to revoke it;
- what audit artifact proves it.
Without that, AI rollouts get stuck in CISO review.
With AZK, this becomes an architecture conversation rather than faith-based AI policy.
Why not just an SDK
An SDK solves developer ergonomics.
AZK solves trust boundary.
These are different layers.
A classical SDK helps you call an API.
But an SDK doesn't explain to an AI agent where the plaintext boundary lies.
An SDK doesn't catch hallucinated integration around the SDK.
An SDK doesn't give a runtime agent a scoped crypto capability.
An SDK doesn't produce the category-level answer for a CISO: "what exactly does the agent see, and what artifact proves it?"
Dev-time MCP can play the role of an AI-native SDK channel.
Runtime MCP can play the role of an agentic control layer.
Together they form the AZK surface.
Where this matters most
ASTIS MCP and AZK matter most for teams introducing AI agents into workflows that touch sensitive data:
- regulated B2B SaaS;
- healthcare / PHI workflows;
- fintech and payment-adjacent systems;
- legaltech and confidential documents;
- AI-first products with customer data;
- enterprise internal copilots;
- security automation;
- compliance automation;
- developer platforms that need to integrate encryption quickly and correctly.
If your AI agent only works with public docs, AZK may be overkill.
If your AI agent touches customer data, PII, PHI, contracts, logs, or regulated workflows, AZK becomes a baseline architecture requirement.
Q&A
Q: Does ASTIS MCP generate the code, or does the AI agent generate it?
A: The code is generated by the AI coding agent inside your IDE. ASTIS MCP gives that agent the ASTIS contract: endpoints, scopes, templates, validator, and threat-model context. More precisely: the AI agent writes the integration; ASTIS MCP makes that generation ZK-aware.
Q: Is this an SDK?
A: Dev-time MCP is an AI-native SDK channel. Not a wrapper library — structured product knowledge for the AI agent: how to integrate ASTIS without hallucinated endpoints and ZK-breaking mistakes.
Q: Is MCP in the runtime data path?
A: For Dev-time MCP — no. It helps generate and validate the code path. The customer application calls the ASTIS API Gateway directly at runtime.
Q: And Runtime MCP?
A: Runtime MCP is a separate layer for production AI agents. Its canonical deployment for sensitive plaintext flows must be customer-side: inside the customer's trust boundary, with explicit scopes and audit.
Q: Why is this AZK?
A: Because an AI agent gains the capability to operate inside cryptographic workflows, but not broad plaintext access by default. Access becomes scoped, operation-bound, and auditable.
Q: Can you say ASTIS MCP is the first AZK product?
A: We're framing AZK as the ASTIS category and positioning. The most precise claim: ASTIS MCP is the first ASTIS product layer for Agentic Zero-Knowledge, and a practical implementation of the AZK approach for AI-agent workflows.
Get in touch
If your team is integrating AI agents into product or internal workflows, the first question isn't:
"Which model provider should we pick?"
The first question is:
What does the agent see at the trust boundary?
If the answer is "everything it has API access to," you don't have an AI security architecture.
You have an unmanaged plaintext access path.
ASTIS MCP exists to change that.
Dev-time MCP helps AI coding agents build ZK-aware integrations.
Runtime MCP gives production AI agents scoped crypto operations inside the customer trust boundary.
That's AZK:
AI agent access without default plaintext access.
If you're running AI agents next to sensitive data, let's not talk about demos.
Let's talk about trust boundary, scopes, and audit artifact.
— Ievgen Bobliev, Founder of ASTIS. ASTIS — cryptographic trust layer.