Admission control vs runtime enforcement for AI agents

Before the Kubernetes API server stores an object, admission control gets a look at it, which is how it can stop an unsafe agent pod from starting. Runtime enforcement watches a running agent’s behavior: the tools it calls and the endpoints it reaches. The admission side cannot see those calls, so agents need both controls.

Source: https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/ (fetched 2026-11-08).

What admission control sees

An admission controller is a piece of code that intercepts requests to the Kubernetes API server after the request is authenticated and authorized, and before the resource is persisted. Mutating controllers run first and may change the object. Validating controllers run after that and may only accept or reject it.

Source: https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/ (fetched 2026-11-08).

Webhooks are the extension point for your own rules. The API server sends an AdmissionReview request to the webhook for each matching request. The webhook’s failurePolicy decides what happens if that call fails. Its timeoutSeconds defaults to 10 and must be between 1 and 30. Webhooks only receive requests that the API server handles, so an agent’s outbound calls never reach them. The governance beyond the admission webhook post makes the same boundary point from the platform side.

What runtime enforcement has to see

An agent is a process that makes decisions and then calls things: a model API, an MCP server, a database, a shell. Most of those calls leave the pod over the network and never touch the API server. The Kubernetes control plane has no record of them, so a policy evaluated at admission has nothing to match against.

Runtime enforcement has to sit where those calls happen. That can be a gateway in the request path, a proxy the agent must use, or a check inside the process or the kernel. The right point depends on which action you need to stop. Whatever the point is, it sees things admission never sees, such as the destination and the identity behind the call. Tool names and arguments are visible only where the check reads the request itself, such as a gateway or an in-process hook. A kernel or network check cannot read arguments inside encrypted traffic.

Where each control stops an agent

The two controls answer different questions, so the table is a map of which one to reach for.

Question	Admission control	Runtime enforcement
Where it runs	Kubernetes API server, through a webhook or a ValidatingAdmissionPolicy	In the request path, the process or the kernel, depending on the tool
When it runs	When an object is created, updated, deleted or connected to	When the agent acts after it starts
What it sees	The object’s spec and metadata, plus the request	Depends on where the check sits: a gateway or in-process hook can see tool calls and arguments; a kernel or network check sees processes, connections and destinations
Example it stops	A pod spec that breaks a rule, such as a missing label	A tool call to a host the agent was never allowed to reach
Failure behavior	Set by failurePolicy; defaults to Fail	Set by the enforcement point; confirm with your vendor
Evidence it leaves	Admission results, and PolicyReports for Kyverno policies	Depends on the tool; treat the logs as part of the control

A decision checklist for agent controls

Run each agent action through these questions in order. The first “yes” tells you where the control belongs.

1. Is the risk visible in the pod spec, such as a host mount, a privileged container or a missing service account? Write an admission rule.
2. Is the risk what the agent’s identity can do against the Kubernetes API? Write an RBAC grant that is as narrow as possible. Admission rules do not replace it.
3. Is the risk a call the agent makes at runtime, to a model, a tool or a data store? You need a control in the request path or the process.
4. Can you test the rule without blocking? Start in audit mode and read the results before you deny anything.

Most agent incidents need more than one answer. A narrow service account limits the damage, and the runtime check limits the call that the account still permits.

Set failurePolicy on purpose

The webhook’s failure mode is a decision, and the default is one of the two choices. With Fail, an outage in the webhook blocks every matching create or update, which is safer for agent namespaces and more disruptive. With Ignore, the same outage lets the workload through with no check. The Kubernetes reference lists both values and states that Fail is the default.

Treat the choice as part of the policy. Record which value each agent namespace uses, and alert when the webhook is unavailable so that a fail-open period is never silent.

Enforcing this with Kyverno

Kyverno covers the admission side of this split. A policy written as a ValidatingPolicy, or as a NamespacedValidatingPolicy for one namespace, is evaluated when the API server handles a matching request. The example below applies to pods in a namespace where agents run and requires each pod to carry an ai-agent label. The object.metadata.?labels.orValue([]) form is the one the Kyverno page uses for optional label access.

Source: https://kyverno.io/docs/policy-types/validating-policy/ (fetched 2026-11-08).

apiVersion: policies.kyverno.io/v1
kind: NamespacedValidatingPolicy
metadata:
  name: agent-pods-require-agent-label
spec:
  validationActions:
    - Deny
  matchConstraints:
    resourceRules:
      - apiGroups: ['']
        apiVersions: [v1]
        operations: [CREATE, UPDATE]
        resources: [pods]
  validations:
    - expression: "'ai-agent' in object.metadata.?labels.orValue([])"
      message: "Pods in this namespace must carry the ai-agent label."

The Kyverno validating-policy page uses Deny and Audit in its examples, but it does not define what each action does. The page does say that evaluation results are recorded in PolicyReports. The steps below are a recommendation for rollout, not documented behavior, so confirm the action semantics on your Kyverno release before you rely on them.

Roll the policy out in audit mode

1. Apply the policy in a test namespace with validationActions set to Audit, then check the results in PolicyReports before you switch to Deny.
2. Create a pod without the ai-agent label and confirm the report records it.
3. Add the label to the agent’s pod template, and deploy the agent under its own named service account, bound to a narrow Role as described in RBAC for AI agents in Kubernetes.
4. Switch the policy to Deny once the audit results are clean.

Where this policy stops

The policy keeps unlabelled pods out of the agent namespace. It does not see the agent’s calls after the pod is running, so keep a runtime control in place for those. The Kyverno policy library for agents has more policies for the pod spec, and governing AI agents from code to runtime covers how the two layers fit together. For the wider picture, see the AI agent governance overview, or the Kyverno project if you want to start with the admission side.

Checked against the Kyverno ValidatingPolicy documentation and the Kubernetes admission webhook documentation, fetched 2026-11-08.

Frequently asked questions

Can an admission webhook stop an AI agent from calling an external API?

No. Admission webhooks run when a request reaches the Kubernetes API server, such as a create or update of a pod or other object. An agent that calls a model provider or an MCP server over HTTP from a running pod never sends that call to the API server, so no admission webhook sees it. Stopping those calls needs a control in the request path, which is runtime enforcement.

Is runtime enforcement a replacement for admission control?

No. Workloads are checked when they are created or changed, which is how admission keeps unsafe pods out of the cluster. Runtime enforcement checks behavior after the agent is running. Use admission to validate pod specs, use RBAC to limit what the agent's service account can do, and add runtime checks for the actions a pod spec cannot describe.

What should happen if the admission webhook is down?

It depends on failurePolicy. Kubernetes defaults a webhook's failurePolicy to Fail, which rejects the API request when the webhook call errors. Ignore lets the request continue unchecked. Most teams that enforce agent policy should keep Fail, and monitor the webhook so an outage is visible rather than silent.

Does a ValidatingPolicy in Kyverno see the agent's tool calls?

It sees the objects submitted to the API server and nothing else. A ValidatingPolicy can require a label on every agent pod in a namespace, as the example below does. It cannot see the prompts, tool arguments or HTTP traffic that the agent produces after the pod starts.