Welcome to part three and four of our multi-part series on AI Invariants. In Part 1 we described the stack and how AI works. In Part 2 we discussed the service models of AI, how we use it, and where the threats are. In this part we’ll discuss the available enforcement points and then start crafting the invariants themselves.

Comments are available on the Google Doc version.

Part 3 - Invariant Enforcement Points

Every generative AI interaction is, at its simplest, sending a prompt to a model and getting a result. That said, there are a range of possibilities for how these interactions route, and for enhancing the process by allowing the model to extend its capabilities and interact with other services. This diagram is a simplified model for tracking these communications, and it helps us describe where invariants can be enforced.

If you are familiar with our work on cloud security invariants you’ll notice one important difference in how we describe AI invariants. In the cloud, nearly all of our invariants have a wider, organization-level, scope. But with AI our scope could be as low as an individual agent on an employee’s laptop. Why? Because the scope in the cloud is typically at the provider level: AWS / GCP Organizations, or Azure Enrollment / EntraID . With AI we may want a security property that always holds true at the level of an individual agent or application.

At the core of it, we have the agent or the user. Both have an objective (goal) and will iterate until they achieve the goal. For humans we have the enforcement points of conscience, consequence and common sense (sometimes). Anything resembling that for the agent happens in the classifiers just before they reach the model.

The first enforcement point is at the harness. The problem is there are dozens, if not hundreds, of harnesses in widespread use. Claude Code CLI, Codex, OpenClaw, and Cursor are just a few examples.

The harness may run in a sandbox. This could be a local container runtime, or something like AgentCore. The runtime sandbox is designed to limit the access an agent has to credentials, tools, and data. It should be noted that the harness itself has some level of “sandbox” capability, but it’s paired with the model and can be somewhat non-deterministic. For our purposes we’ll only consider the runtime-sandbox as an enforcement point.

The harness and its runtime-sandbox run somewhere on a host. This gives us another enforcement point with MDM and EDR (if that host is an endpoint). We can ensure that the harness is configured in a specific way, that only specific tools are available, and that the path from the local harness to the remote harness passes though some sort of proxy, firewall or CASB. Server-based harnesses, like you would build in your cloud provider, won’t use MDM or EDR but provide similar levels of control since you own the entire operating system and platform configurations. This is where your cloud invariants can support your AI invariants.

From there, the agent or user’s context will travel over a network (including localhost) to where the inference will happen. There, an additional part of the harness, what we’re calling the inference-harness, will take the entire context, potentially augment it with additional instructions, process it through classifiers, tokenize it, and then pass it to the model. The model produces its output, output classifiers are run, and the result is returned to the local harness.

The process could decide that the use of tools is needed to achieve the goal. The local or inference harness could make a call out to an MCP or CLI to perform an action or gather more data. What tools can be called can be enforced by the runtime-sandbox, the host, or the local or remote harness.

How an agent is identified by the various systems a tool may call is the final enforcement point. The distinct identity an agent has, the method of authentication, and the actions it’s authorized to perform are the final three pieces to the puzzle.

Invariants can be enforced at different points depending on the security property, and the scope. In our next section we’ll use the numbering in the diagram to identify possible enforcement points for each invariant we describe. But, keep in mind, these aren’t absolute since AI is a rapidly evolving technology and different vendors and platforms have wildly different architectures and capabilities.

Part 4 - The AI Security Invariants

Now that we’ve covered how AI is built, used, and the broad AI- specific threat landscape, we can finally start digging into the actual list of Invariants an organization might implement. This will vary, depending on the regulatory environment, risk profile, and technical capabilities. This is not intended to be a one-size-fits-all checklist to implement, or a complete list of all possible invariants, but rather a series of example invariants that you could implement to meet your specific needs.

1. Only approved inference providers can be used.
   1. This can be enforced through network security controls that block access to unapproved inference providers (e.g. HuggingFace, neoclouds, Anthropic, OpenAI, Google, xAI, etc.).
   2. This can be reinforced using MDM to prevent installation of the local tools for those providers, and local FQDN blocking if that’s supported by your endpoint security tooling.
   3. Within a given runtime platform, like AWS, you can set organization-level controls to restrict in-use providers.
2. Only approved models can be used.
   1. For endpoints, the inference providers are blocked with the previous invariant, and the specific models in your approved providers are managed within the provider’s controls, often tied to RBAC. For example, you can allow a more cost-effective version of Claude or OpenAI but block use of their most expensive models except for some users.
   2. For SaaS, your SaaS provider may or may not allow you to enable/disable the AI feature and may or may not support RBAC for only allowing select users access.
   3. For AI you build into your applications, this can be controlled at the model provider or your third-party inference provider. Many support the concept of allowed models or limiting model access based on API token.
3. Only approved harnesses can be used.
   1. The harness is software, and you enforce the approved software via your MDM or EDR.
   2. Where the harness is not running on a managed endpoint, your SBOM becomes a detective control, but that’s not invariant.
   3. When building your own applications, the harness can be enforced through the CI/CD pipeline (assuming you have blocking gates in use).
4. Only approved tools can be used.
   1. This can be enforced a number of ways, depending on the harness and the runtime sandbox.
   2. SaaS providers like Claude or OpenAI Enterprise give administrators control over what plugins, MCPs, or tools are allowed.
   3. On Endpoints, MDM and EDR can be used to block specific processes.
   4. On enterprise-deployed runtime-sandbox environments, the tools available to call via CLI or via MCP can be managed.
   5. When using an AI gateway, or building AI into your own applications (with a provider gateway, such as AWS AgentCore Gateway), this can be enforced using the gateway.
5. AI agents must never use tools that hold a human’s primary credentials (such as passwords, sessions, or long-lived keys). Agent access to any resource must be through a grant that can be revoked without disabling the human.
   1. Agentic tool usage is enforceable via MDM for local tools ; via the Inference Provider for SaaS based harnesses.
   2. This can be enforced at a gateway or in the code of the MCP server/tool itself (e.g. via OAuth implementation).
6. An agent must never use tools that allow the agent to hold more authority than the human who tasked it.
   1. Agentic tool usage is enforceable via MDM for local tools ; via the Inference Provider for SaaS based harnesses.
   2. This can be enforced at a gateway or in the code of the MCP server/tool itself (e.g. via OAuth implementation).
7. Destructive and irreversible actions must be performed by a human.
   Alternate Version: An agent may never be able to execute an irreversible destructive action.
   1. This can be enforced in the runtime sandbox by ensuring the credentials scoped to the agent do not permit destructive actions.
   2. This can also be enforced via the Cloud Providers, assuming the agent can be distinguished from the user.
   3. This can be enforced in various ways using inline deterministic guardrails that evaluate the tool actions.
8. AI-generated code must only reach production through the same review and deployment pipeline as human-written code.
   1. This can be enforced in the runtime sandbox by ensuring the credentials scoped to the agent do not direct production mutations.
   2. Enforcement also requires credentials without the ability to bypass branch protection.
9. All company inference must occur inside the European Union [or selected jurisdiction].¹
   1. Enforcement must be implemented within the inference environment, combined with network security controls mentioned above to prevent network access to non-approved inference providers.
10. An AI system must never be the sole decision-maker for a legally consequential decision affecting an individual (hiring, lending, benefits eligibility, medical).²
    1. Enforcement must happen at the product level. A human must make the decision; the AI may inform it.
11. Every model invocation and tool call in a high-risk application must be logged³ with its complete input and output, so the agent’s actions can be fully reconstructed.
    1. Enforcement at the Inference Environment provides the enforcement point least likely to be bypassed. Alternatively, an LLM Gateway configured between the host and the inference harness could capture this data for auditability.
12. Every AI workload must run under an enforced consumption quota. (Enforced meaning throttled, not alerted-on-and-billed.)
    1. This can only be enforced by the inference environment as requests are made and the bill is updated.

As a reminder, these are just common examples and you will likely only use some of these, and add your own. For example, one of the authors recently implemented an AI platform with an invariant “for any given inference call or AI agent, only the current customer’s data is accessible during a given session”. This was enforced using a combination of IAM, code, and data structures, plus specific adversarial testing in the CI/CD pipeline to ensure future code changes don’t reduce the invariant (blocking test in CI/CD).

Notes on wording

Invariants must always be true, so where an exception is needed, it is built into the wording. “No one can create a VPC” is unworkable because that action needs to occur. The correct wording is “only the networking administration team can create a VPC.” An invariant gets a named exception owner only when the absolute form is impractical to live with; the bracketed placeholders ([security], [legal], [privacy], [platform team]) are each organization’s exception owner. Invariants without one are absolute by design.

Guardrails vs Invariants

While writing this paper, we brainstormed a large number of possible invariants we’d want to implement in the organization s we support. However in many cases the “will always hold true” requirement could not be met in a way that is defensible to auditors, regulators, management, or the board. What we were writing were guardrails, not invariants.

An AI guardrail is a point solution intended to stop a misconfiguration or misbehavior. They have to be applied wherever there is a danger zone. For guardrails that protect against misbehavior, they often have to be baked directly into the agentic AI application. For misconfigurations, a guardrail that relies on a human isn’t an invariant. The best guardrails to use for invariants should be:

1. Applied broadly across the organization
2. Centrally managed by a security or governance team
3. Defensible to auditors and regulators that it “always holds true”

An AWS Service Control Policy to prevent the creation of unauthorized IAM Access Keys fits these three criteria. It’s deployed at the AWS Organization, so it’s broadly applied. It’s centrally managed by the team that manages the AWS Organization. And it’s enforced via AWS IAM which has a long track record and artifacts to back it up.

“The [platform team] must always be able to halt any high-risk company AI system immediately, including mid-task” enforces an important regulatory requirement under the EU’s AI Act. It needs to be implemented as a guardrail in the scope of the high-risk system.

From Concept to Enforcement

Our next set of posts will look at what enforcement points are available in the major cloud providers and AI Labs. Stay Tuned.