Enterprise AI security architecture

Enterprise AI security architecture is not a vendor questionnaire you file and forget. It is identity on every call, a path that can fail closed, data-class rules on the wire, and a way to shut a write off at 2 a.m. A model provider's SOC report is input. It is not your architecture.

The hop is the LLM gateway. Tools sit behind MCP with the same identity story. This post is the security cut. No invented threat scores. No package SKU.

If you cannot name who can send a prompt and who can read the log, you do not have architecture. You have apps.

Identity first, then models

Every inbound call has an app identity. When a person is in the loop, their identity or a narrower delegate reaches retrieval and tools. A shared "ai-bot" service account that can see every file is a breach waiting for a prompt.

Hold:

• No god-mode keys in laptops or CI logs.
• Upstream provider keys live only on the gateway, in a secret store you control.
• Joiner/leaver process includes AI apps and prompt-log ACLs.
• Break-glass access to raw traces is gated and logged.

Yes/no:

• A revoked user loses model and tool access the same day they lose the source system.
• You can rotate a provider key without editing twelve apps.
• Security can list the identities that may call production routes.

If those are no, stop adding models. You are multiplying keys.

Fail closed on the hop

Security architecture assumes the app will try something stupid: the wrong model, the wrong region, a write tool, a blocked class. The gateway denies. The app degrades. That is success.

Build for:

• Missing data class on a high-risk route → deny, not "best effort."
• Unknown app identity → deny.
• Tool not on the allow list → deny.
• Budget or rate exceeded → deny or queue, with a page in production.

Failing open because "the demo must work" is how you get the demo in production. Staging can be looser. Production cannot.

Egress matters. If a developer can still reach the provider with a personal key, your architecture is advisory. DNS, package allow lists, and a paved client make the official path the easy one. You will not get to zero bypass. You can make bypass obvious in logs.

Data class is a security control, not a privacy slide

Restricted data (PII, health, payment, credentials) does not go to a consumer model, a personal account, or an unlogged SDK. Confidential business data stays on contracted tenants in pinned regions. Public copy can be cheaper and faster.

The architecture maps class → route → redaction or block. Leakage prevention is the next post. The security rule is simpler: class is evaluated before the payload leaves.

Prompt logs inherit the class. A debug bucket that stores raw customer prompts is a store you have to defend. So is a Slack export of "fun completions."

Vendor evaluation still applies: residency, retention, who at the vendor can read prompts, subprocessors, exit. Their controls do not replace yours. They sit on the other side of your hop.

Incident is a first-class path

Write two stories: the model was wrong, and data left. They have different severity.

You need:

• Who is paged, what write tools go off first, who talks to a customer.
• How to pull the trace and the inventory row in the first hour.
• A post-incident note that updates eval, the allow list, or the tier.

Observability is how you find the trace. Architecture is how you turn the server off. If off means "email the vendor," you do not own the incident.

Drill it once. A handbook-only path is a wish.

Scope the first route, then expand

Do not draw a zero-trust poster with twelve models. Put one production app on the hop. Prove deny, rotation, and a log pull. Then the second app. High-risk writes stay gated.

We implement this in your environment, mapped to NIST GOVERN (who may call), MAP (what it is), MEASURE (logs), MANAGE (deny and incident). You own the deploy. We do not publish a security appliance SKU.

If the architecture still depends on a laptop key, it is not an architecture. If you want the hop designed as engineering, talk to an engineer.