Deployment and architecture questions

The first thing a reviewer wants is a diagram, and the second is the list of things that break. This page answers both without a diagram: where the layer sits, what it needs to run, what the application has to change, and how it behaves when something goes wrong.

Where does SecureAI Guard sit in the request path?

Inline, between your application and the model it calls. SecureAI Guard is an enterprise security layer for LLM and generative-AI applications: it sits inline between an application and the models it calls, inspecting prompts and completions in both directions to enforce policy server-side.

That position is the whole design, and everything else on this page follows from it. A control placed anywhere else answers a different question. A filter in the browser can be edited by the person it is filtering. A log pipeline that reads model traffic after the fact can tell you what happened but cannot stop it. A prompt instruction ("never reveal the system prompt") is a request to the model, not an enforcement point, which is why prompt injection is not closed by writing a better system prompt.

Does it run server-side or in the client?

Server-side, always. A control that runs in the client is advice, not enforcement: the client can be modified and the model endpoint called directly with whatever the attacker prefers. This is stated as a design property on the security page and it is worth checking in any security layer you evaluate, ours included.

The practical consequence is that your model credentials and your policy decisions stay on infrastructure you control, and a compromised or hostile front-end cannot remove the check by not calling it.

Does it inspect model output as well as prompts?

Both directions. Input-side inspection alone cannot enforce output handling, and the output side is where a successful attack usually becomes visible — an injected instruction that succeeded produces a completion containing data, credentials or a tool call that should not be there.

A layer that only sees prompts can be evaluated on prompts. Ask any vendor, including us, to demonstrate an output-side decision on your own traffic rather than describing one.

Can it run without prompt content leaving our network?

Yes. Running SecureAI Guard inside your own infrastructure is a documented deployment model — see on-premises deployment — and it is the only answer that fully resolves a data-residency requirement, because no choice of processing region changes the fact that content left your boundary.

If the reason you are asking is a regulatory constraint rather than a policy preference, start at GDPR and LLM data handling, which is where the residency argument actually begins, and then read data residency for what is and is not settled about the hosted service today.

What does a self-hosted deployment need?

The prerequisites published on the on-premises deployment page are:

• a server or virtual machine with at least 16 GB of RAM and 4 CPUs;
• Docker installed on that host;
• credentials for the SecureAI Guard private container registry, issued with an evaluation or enterprise agreement — the image is not published to a public registry, and the site deliberately publishes no docker pull command for a public namespace;
• network access to any external services your configuration enables, such as threat-intelligence feeds.

Configuration is a config.yaml mounted into the container, and the service listens on port 8080 by default. Anything beyond that — sizing for your request volume, high-availability topology, upgrade procedure — is not published on this site. Ask for it during an evaluation and get the answer in writing.

Does our application code have to change?

Something has to change, because the traffic has to reach the layer. What changes depends on where you attach it, and there are only a few shapes:

• Point the model client at the security layer. Most model SDKs expose a base-URL option for exactly this — the Anthropic SDKs document a base_url client option and an ANTHROPIC_BASE_URL environment variable, and Google's google-genai SDK documents HttpOptions.base_url explicitly for putting an API gateway proxy in front of the API. This is usually a one-line change per service.
• Attach inside the framework. LangChain and LlamaIndex both document extension points that run around every model call; see integrations for what each one exposes and what it can enforce from there.
• Call a check explicitly. Some platforms give you a standalone evaluation call to make before or after the model call, decoupled from the model invocation itself.

Which of these SecureAI Guard supports for your stack is not something this site states, and you should not infer it from the fact that we describe the pattern. The supported models and frameworks page is where that list belongs, and it is unfilled today.

What happens to our traffic if the security layer is unavailable?

You have to choose, and you have to choose before you deploy. There are two behaviours and both are defensible:

• Fail closed. The model call is refused when the layer cannot make a decision. Nothing unchecked reaches the model, and an outage in the security layer becomes an outage in the feature it protects.
• Fail open. The model call proceeds unchecked. The feature stays up and the control silently stops applying, which is the worse failure if the control is the reason you are allowed to run the feature at all.

This site does not publish which of those SecureAI Guard does by default, or how it is configured, and we are not going to imply an answer here. Ask for it in writing, ask what the timeout is, and ask what is logged when it happens. A vendor who cannot answer that in one sentence has not thought about it, which is the actual thing you are testing by asking.

The same question applies to your own architecture: if the layer is in the synchronous path of a user-facing request, its availability is now part of your availability budget. That is not an argument against inline enforcement — it is the cost of enforcement being real — but it belongs in the design review rather than in the incident.

Does it protect an agent that calls tools?

Only the parts of an agent that pass through the model endpoint. An inline layer sees prompts and completions, which for an agent includes tool definitions and tool results, because those are carried in the model request and response. It does not see a tool executing, and it cannot enforce what a tool is permitted to do once your code has decided to call it.

That gap is the substance of AI agent security: the enforcement point for "may this agent write to that system" is the tool's own authorisation, not the model's context. Treat an inline layer as one control in that chain, not as the chain.

Where to go next

• Data handling questions — what the layer can see and what happens to it afterwards.
• Latency and performance — what inline inspection costs, and how to measure it before you commit.
• Integrations — the documented attachment point in each framework and model API.
• Implementation guide — the worked integration walkthrough.