Let AI agents work on your cluster
Keep the changes you never want made unattended behind a protection plan, see what an agent tried, and roll back what got through.
An AI agent with cluster credentials (kubectl, an MCP server, an automation bot) changes your cluster through the same Kubernetes API as everyone else. Telark checks those changes at admission, so a protection plan holds even when the agent ignores its instructions.
A plan applies to every writer in its scope: people, pipelines and agents alike. Protect the changes nobody should make unattended, then check what the agent did.
You need: the Contributor role or higher on protection plans. Enforcing on a namespace scope needs the Owner role.
1. Give the agent its own identity
Run the agent with a dedicated ServiceAccount, with RBAC limited to the namespaces and verbs it needs. RBAC decides what the agent can reach at all. Telark decides what it can change, and when.
A request a plan blocks or audits names the Kubernetes user that sent it, so a dedicated ServiceAccount makes the agent's attempts easy to find.
2. Protect what an agent should never change alone
Create a protection plan with the Permanent schedule over the applications or namespaces the agent works in. Templates that fit:
| Template | Keeps the agent from |
|---|---|
| Deleting any resource | Removing workloads while "cleaning up" |
| Changing replica counts (applications scope only) | Scaling a workload to zero |
| Creating, deleting or editing storage | Touching volumes and their data |
| Updating or deleting ConfigMaps & Secrets | Rewriting configuration and credentials |
| Images with blocked tags | Deploying tags you list, such as latest |
These rules hold for everyone in scope, people included: a plan can't exempt one identity. To make one of these changes yourself, cancel the plan and reactivate it afterward. A plan that needs approval asks for it again.
3. Audit first, then enforce
Create the plan in Audit mode: Telark records what it would block and blocks nothing. Let the agent work, then open the plan's Admission decisions. Each one names the resource, the policy and the Kubernetes user who sent the request.
When the decisions show only changes you meant to stop, edit the plan and set the mode to Enforce. An approved plan refuses that edit: duplicate it in Enforce mode instead, and the copy asks for approval again. The agent's requests that break a rule now fail at admission with a message that names the plan.
4. Check what got through
Every change that reaches an application is in its change history, down to the field, with a snapshot of the manifests just before it. Roll back anything you don't want.
Telark stamps the Kubernetes user of every create and update on workloads, ConfigMaps, Services, PersistentVolumeClaims, ServiceAccounts, Ingresses, NetworkPolicies and autoscalers, outside the system namespaces and Telark's own, so the history shows which changes came from the agent's ServiceAccount. Deletes and Secrets carry no author.