Secure AI environment establishment

Most of the AI security market sells you a test or a platform. Neither builds the thing that was missing: an environment where the AI your organization actually wants to use runs on credentials it should have, through a path somebody owns, leaving a record that survives the question asked six months later.

Who buys this

Two situations, usually the same organization six months apart. The first is a company standing up its first sanctioned AI capability and wanting it built properly rather than retrofitted. The second is a company that has seen its shadow-AI inventory and now needs somewhere to send people that is better than what they found on their own.

A prohibition without an alternative produces unmanaged use you cannot see. This is the alternative.

Target-state architecture

The design is written for your stack, but the shape is consistent: a single enforcement point, guardrails placed where they are cheap, credentials that are narrow by construction, and telemetry rich enough to reconstruct events. Each layer below is specified concretely — component, placement, owner and the control it enforces.

LayerWhat it has to do
Gateway or brokerEvery model call leaves through one place that authenticates the caller, attaches the credential, applies policy and writes the log. Without it, nothing below is enforceable.
Input guardrailsClassification and policy checks on what goes in: regulated data categories, known injection patterns, and the boundary that marks retrieved content as data rather than instruction.
Output handlingTreat model output as untrusted input. Encode before render, never execute, parameterize before query, and validate structure before a downstream system acts on it.
SecretsModel keys and tool credentials issued to the gateway, short-lived, rotated, and never present in a prompt, a client bundle or a notebook.
Egress controlModel and tool traffic leaves by known routes to known destinations, so an exfiltration path through a tool call is a policy violation rather than ordinary outbound traffic.
Tool credentialsScoped per agent and per user, least privilege by construction, with destructive capabilities separated from read ones.
TelemetryPrompts, retrievals, tool calls and outputs recorded with correlation identifiers, so an incident can be reconstructed rather than guessed at.

The reference frames are NIST AI RMF 1.0 with the Generative AI Profile (NIST AI 600-1) for the control set and NIST SP 800-218A, Secure Software Development Practices for Generative AI and Dual-Use Foundation Models where the environment is also a development environment.

The gateway, and what belongs at it

The gateway is not an optimization. It is the one place where a policy can be applied to every model call in the organization, and the reason every control downstream is enforceable rather than advisory. At it: authentication of the caller and resolution of who they are; attachment of the model credential the caller never holds; per-team and per-user budget limits; routing and model pinning; and the log write.

A design that lets one team call a provider directly has no gateway. It has a proxy that most traffic happens to use, which is a different and much weaker thing. The rollout plan treats closing the direct paths as a milestone, not a cleanup task. Patterns and trade-offs are set out in AI gateway and guardrail patterns.

Guardrails at input and output

Content filtering helps in specific places and is theatre in others. It works on volume: catching regulated data categories before they leave, catching known injection patterns cheaply, refusing output shapes the application cannot safely consume. It does not work as a boundary, because a model cannot be relied on to separate instruction from data, and a filter tuned hard enough to stop a determined attempt breaks the feature.

So guardrails are designed as one layer of several rather than as the boundary. The boundary is what the system is permitted to do: narrow credentials, approvals on destructive actions, and output that is encoded and validated before anything acts on it. Retrieval-side placement is covered in RAG and vector store security; action-side placement in agentic AI and MCP security.

Secrets, isolation and least privilege

  • Secrets handling. Model and tool credentials live in the secret store, are issued to the gateway, and are short-lived. They never appear in a prompt, a system prompt, a client bundle or a notebook. A credential in a prompt is a credential published to everyone who can make the model repeat its context.
  • Network isolation and egress control. Model and tool traffic leaves by known routes to an allowlist of destinations. Self-hosted inference sits in its own segment. This is what turns an exfiltration attempt through a tool call from invisible outbound traffic into an alert.
  • Least-privilege tool credentials. Scoped per agent and per user, not one service account shared by every integration. Where an action is destructive or moves money, it is a separate credential with an approval on it.

Canada’s Centre for Cyber Security sets out the same posture for generative AI in ITSAP.00.041, including the plain instruction to avoid providing personal or sensitive corporate data in queries and prompts — which is a control the environment should enforce rather than a rule staff are asked to remember.

Why the logging design is not optional

This is the part most AI rollouts leave until after the first incident, and it is the only part that cannot be added retroactively. An AI incident cannot be reconstructed without telemetry designed in beforehand: if the prompt, the retrieved documents, the tool calls and the output were not recorded together with a correlation identifier, then after the fact there is no way to establish what the model was told, what it reached, or what it did.

Every other kind of investigation has a substrate — packet captures, disk images, database logs. An AI interaction that was not logged leaves nothing at all. So the design specifies what is captured at each layer, how long each class is retained, how prompts containing personal information are handled and minimized, and who may read them. Done at design time this is a configuration decision. Done after an incident it is an apology.

This is the preventive, advisory form of an investigation capability, and it is what makes AI security monitoring and detection possible and AI incident readiness meaningful. The audit logs it produces are an ordinary engineering artifact: a record of who did what, kept so it can be read later.

Private deployment and data residency

Residency is settled by three answers, not one: where inference runs, where prompts and outputs are retained, and who can reach either from outside the chosen region for support or abuse review. Answer all three and the hosting decision usually makes itself.

Self-hosted or private deployment buys control over all three and costs real engineering: capacity planning, model updates, evaluation when a model changes, and the security of the inference layer itself. A pinned region with a provider that commits to it contractually is often the better trade, and the design says which trade was made and why, so the decision survives the next architecture review.

Self-hosting is a control, not a virtue, and it is the right answer only when a specific constraint demands it: a residency commitment a provider will not make, a data class that may not leave a network, or a regulator that requires the processing location be named. Where personal information is involved, the residency answer is a factor in the organization’s obligations under PIPEDA or, for a British Columbia public body, the Freedom of Information and Protection of Privacy Act — questions to settle with your counsel, not to answer from an architecture diagram.

What you receive

  • A reference architecture for your stack: components, placement, data flows and trust boundaries, drawn so an engineer can build from it.
  • A control set — each control stated with its owner, its enforcement point, and the evidence that shows it is working.
  • A phased rollout plan: what ships first, what the first cohort is allowed to do, and the milestone at which the direct paths to model providers are closed.
  • Implementation support, optional, alongside your engineers while they build it.

The design, the control set and the rollout plan are ours to produce; the building is done by your engineers with us alongside them, reviewing the implementation against the design and fixing what drifted. Running the environment afterwards is an operation rather than advice, and it stays with you.

How the work is bounded

The scope is agreed in writing before work starts, and the engagement is quoted in writing with it.

SecHB does not issue certifications, attestations or audit opinions: those come from accredited certification bodies, CPA firms and QSAs. The work here is what an organization does to be ready for them.

Nothing here is legal advice. Where a question turns on the law, the work is done alongside the client’s counsel, not instead of them.

Questions we are asked

Do we need to self-host our models?

Self-hosting is a control, not a virtue, and it is the right answer only when a specific constraint demands it: a residency commitment a provider will not make, a data class that may not leave a network, or a regulator that requires the processing location be named.

Does an AI gateway slow everything down?

A gateway adds a small, measurable amount of latency and removes an unbounded amount of uncertainty. The overhead that matters comes from synchronous output checks, not from proxying, so the design puts the slow checks only where a wrong answer is expensive.

Can you build it for us, or only design it?

The design, the control set and the rollout plan are ours to produce; the building is done by your engineers with us alongside them, reviewing the implementation against the design and fixing what drifted.

What about AI data residency in Canada?

Residency is settled by three answers, not one: where inference runs, where prompts and outputs are retained, and who can reach either from outside the chosen region for support or abuse review.

Design the environment before the next feature ships

Describe your cloud, your identity provider and the first two AI use cases. The reply says what the target-state design would cover and in what order it would roll out.

Discuss a scope