Welcome to parts three and four of our 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 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 back a result. That said, there are a range of possibilities for how these interactions route, and for enhancing the process by allowing a model to extend its capabilities and interact with other services. This diagram is a simplified model for tracking these communications, and helps 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 our invariants have a wider – organization-wide – scope. But with AI our scope can be as narrow as an individual agent on an employee’s laptop. Why? Because 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. Each has an objective (goal), and will iterate until it achieves its 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 that 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 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 a protected 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, don’t use MDM or EDR but provide similar levels of control through your ownership of operating system and platform configurations. This is where cloud invariants can support AI invariants.

From there, the agent’s or user’s context will travel over a network (which could be a localhost link) to where inference will happen. There an additional part of the harness, what we call 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 output, output classifiers are run, and the result is returned to the local harness.

This process can decide that additional tools are needed to achieve the goal. The local or inference harness could call out to an MCP or CLI to perform an action or gather more data. Which tools can be called may 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 of the puzzle.

Invariants can be enforced at different points depending on the security property, and on the scope. Our next section refers back to that diagram to identify possible enforcement points for each invariant. But these aren’t absolute – 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 varies depending on 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 you can implement to meet specific needs.

1. Only approved inference providers can be used.
   1. This can be enforced through network security controls which block access to unapproved inference providers (e.g., Hugging Face, neoclouds, Anthropic, OpenAI, Google, xAI, etc.).
   2. This can be reinforced using MDM to prevent installation of 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 provider use.
2. Only approved models can be used.
   1. For endpoints 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 provider may or may not allow you to enable/disable their AI feature, and may or may not support RBAC to only allow 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 using API tokens.
3. Only approved harnesses can be used.
   1. The harness is software, and you enforce the approved software via MDM or EDR.
   2. Where the harness is not running on a managed endpoint your SBOM becomes a detective control, but that’s not an 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 and OpenAI Enterprise give administrators control over which plugins, MCPs, and 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 (using a provider gateway such as AWS AgentCore Gateway), this can be enforced using the gateway.
5. AI agents must never use tools which hold a human’s primary credentials (such as passwords, sessions, or long-lived keys). Agent access to any resource must be through a grant which can be revoked without disabling a human.
   1. Agentic tool usage is enforceable via MDM for local tools, and via the Inference Provider for SaaS-based harnesses.
   2. Tool usage can be restricted at a gateway or in the code of an MCP server/tool itself (e.g., via OAuth implementation).
6. An agent must never use tools which allow the agent to hold more authority than the human who tasked it.
   1. Agentic tool usage is enforceable via MDM for local tools, and via the Inference Provider for SaaS-based harnesses.
   2. This can be enforced at a gateway or in the code of an MCP server/tool itself (e.g., via OAuth implementation).
7. Destructive and irreversible actions must be performed by a human.
   Alternate Version: An agent must never be able to execute an irreversible destructive action.
   1. This can be enforced in a runtime sandbox by ensuring the credentials scoped to the agent do not permit destructive actions.
   2. This can also be enforced via a Cloud Provider, assuming the agent can be distinguished from a user.
   3. This can be enforced in various ways using inline deterministic guardrails which evaluate 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 other required jurisdiction].¹
   1. Enforcement must be implemented within the inference environment, combined with network security controls mentioned above, to prevent network access to unapproved 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; an 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 merely alerted-on-and-billed.)
    1. This can only be enforced by an 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 (a blocking test in CI/CD).

Notes on Wording

Invariants must always be true, so where an exception is needed it must be 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 organizational exception owners. Invariants without exception 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 organizations we support. However in many cases the “will always hold true” requirement could not be met in a way 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. Guardrails that protect against misbehavior often must 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 as “always 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 a 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.