Private AI Security: How Enterprise Data Actually Stays Protected
Security on a private AI deployment isn't a checkbox added before go-live — it's the reason the architecture looks the way it does. Every layer described on the architecture page (identity, routing, permissions, the model, the boundary, the logs) exists because of a specific thing it's protecting against, and this page is where those layers are explained from the security side rather than the systems-diagram side.
None of what follows is unique to Echnotek — it's the same controls an enterprise's own infrastructure and security teams already run for every other production system, applied to the AI layer instead of exempting it.
Six Layers, Each Independently Secured
Nothing here is a single control doing all the work — a request that got past one layer still has five more to clear.
Every request — human or agent-initiated — is authenticated against the enterprise's existing identity provider (SSO/IAM) before it reaches anything else. There's no separate credential store for the AI system, no shared API key standing in for a real user, and no anonymous access path into the model or the data behind it.
NO SHARED KEYS, NO ANONYMOUS ACCESS.The model, the retrieval index and any connected tools sit in separate network zones, with only the specific connections the architecture actually needs left open. This is standard defence-in-depth: it limits what's reachable if any single component is compromised, rather than trusting the network boundary alone.
TIERS SEPARATED, NOT ONE FLAT NETWORK.Data is encrypted at rest and in transit, with keys held in your own key management service — not a key Echnotek controls. This applies to the model's working data, the retrieval index, and the logs, not just the primary data store.
YOUR KEYS, NOT OURS.An agent's access is role-based and least-privilege, mirroring how a human employee's access would be provisioned. Guardrails evaluate a proposed action against policy before it executes — what's permitted outright, what needs human sign-off, and what's blocked regardless of what the model proposes.
RISK-TIERED, NOT ALL-OR-NOTHING.Every request, retrieval, tool call and model decision is logged inside your own environment — not exported to a third-party platform by default. A specific action can be reconstructed months later: who triggered it, what data it touched, who approved it.
RECONSTRUCTABLE, MONTHS LATER.The model runs inside the deployment boundary with no route to a public model API, and — depending on the deployment option — on infrastructure dedicated to you rather than a shared, multi-tenant instance. Fine-tuning happens on your data, for your model only.
NO SHARED INFERENCE, NO ROUTE OUT.The Failure Modes Each Layer Exists For
Every control above maps to a specific way a system like this can actually fail — not a generic "we take security seriously."
A prompt, a retrieved document or a model response routed to an external API — the failure mode a private deployment exists to remove entirely.
Malicious or manipulated content inside a retrieved document attempting to redirect the agent into an action it wasn't asked to take.
An agent handed a standing, general-purpose credential instead of a scoped action — the difference between one compromised call and one compromised system.
A refund, an external email, a contract change executing automatically with no human checkpoint at the risk tier that needs one.
An action nobody can reconstruct after the fact — no record of what was retrieved, what was decided, or who approved it.
Fine-tuning or feedback data quietly training a model instance other customers also query.
Built to the Regulation, Not Retrofitted to It
GDPR, the EU AI Act, ISO 27001 and SOC 2 shape the architecture from the first workshop — not a checklist run before launch.
Lawful basis, data minimisation and residency agreed with your data protection team before any data moves — including for logs and backups, not just the primary dataset.
Risk classification, human oversight and documentation matched to the system actually being deployed — recruitment and other high-risk categories get the stricter controls the regulation requires.
Access control, key management and change control on the deployed stack, evidenced by the system itself rather than assembled for an audit after the fact.
Evidence your auditors can use, produced continuously by logging and access review, not reconstructed retroactively.
The Same Controls, Different Boundaries
Every layer above applies in all four deployment options — what changes is who operates the boundary and how far outside it a connection can reach.
| Deployment | Who holds the keys | Network exposure |
|---|---|---|
| Private Cloud | Echnotek, under contract | Dedicated tenancy, no public route |
| Customer VPC | You, in your own KMS | Your VPC, existing network paths only |
| On-Premise | You, on your own hardware | Internal network only |
| Air-Gapped | You, fully offline | No route to the public internet at all |
Private AI Security FAQ
Yes — that's the intended order. Discovery starts with your security, legal and infrastructure teams in the room, and the architecture is documented and signed off before code is written, not demonstrated to them afterward.
The architecture and access model are reviewed against your existing security framework before deployment. If your organisation requires an independent penetration test as part of that process, it runs against the deployed system the same way it would for any other production service you operate.
They stay yours — logs are retained inside your own environment on your own retention policy throughout, so there's nothing to hand over or lose access to when the engagement ends.
Because every request, retrieval and tool call is logged inside your own environment, the investigation runs against a record you already hold, not an export we'd need to provide — your existing incident response process applies to this system the same way it applies to every other one.
Echnotek and the cloud account the system runs in — that's the full list. There's no model vendor, embeddings API or third-party logging platform sitting between your data and the boundary you approved.
Security, in Context
This page is the security layer underneath the rest of the cluster — read it alongside the architecture it's securing.
Bring your security review to us before we build anything.
We'd rather answer the hard question in week one than after a pilot your security team is about to block. Bring your CISO or security lead — that's who we want in the first call.