Trust and Control in Agentic AI: Building the Security Control Plane for Autonomous AI Systems

The AI industry has moved from chatbots to agents. An AI chatbot answers questions. An agentic AI system takes actions: it reads your email, queries databases, calls external APIs, modifies files, creates pull requests, deploys infrastructure, and makes decisions that have real-world consequences. The difference isn't just capability — it's risk.

When a chatbot hallucinates, you get a wrong answer. When an autonomous agent hallucinates, it might delete your production database, send confidential data to the wrong API, or deploy a misconfigured service to a regulated environment. The blast radius of an AI mistake scales directly with the permissions the agent has been granted.

This article describes the security control plane for agentic AI: the infrastructure layer that ensures autonomous agents operate within defined boundaries, with appropriate permissions, under continuous monitoring, and with the ability to stop them at any time. Think of it as the Kubernetes of AI governance — a control plane that manages the lifecycle, permissions, and observability of AI agents in production.

Why Prompt Engineering Isn't Enough

Many agentic AI deployments rely on system prompts for safety: "Don't access production databases." "Don't modify files outside your workspace." "Ask for confirmation before sending emails."

This is not security. This is a suggestion to a probabilistic system. Prompt-based guardrails:

• Can be bypassed by prompt injection: A malicious input that overrides the system prompt can make the agent ignore its safety instructions
• Are not enforceable: There's no mechanism to prevent the agent from taking a forbidden action — only a request not to
• Don't produce audit trails: "The system prompt said not to" is not a compliance-worthy control. Regulators need technical enforcement, not polite instructions
• Degrade with model updates: A model that respects a system prompt today may not respect the same prompt after a fine-tuning update or version change

Real security for agentic AI requires infrastructure-level controls that work regardless of what the model decides to do.

The Agent Security Control Plane

Layer 1: Identity and Authentication

Every AI agent needs a verifiable identity — not a shared API key, not a human user's credentials:

• Agent identity: Each agent instance gets a unique service account with machine-verifiable credentials (X.509 certificate, OIDC token, or cloud workload identity)
• No shared credentials: If three agents run in the same cluster, each has its own identity. When Agent A accesses a database, the audit log shows Agent A — not "ai-service-account"
• Short-lived credentials: Agent tokens expire and must be refreshed. If an agent is compromised, the credential window is bounded
• Human delegation chain: Every agent action should be traceable to the human who authorised the agent. Agent A acts on behalf of User X — both identities appear in audit logs

Layer 2: Least-Privilege Authorisation

Agents should have the minimum permissions required for their task — not "whatever the developer thought might be useful":

# Agent RBAC Policy (Kubernetes example)
# Agent: code-review-agent
# Purpose: Reviews pull requests and posts comments
# Permissions: READ source code, WRITE PR comments
# Explicitly denied: merge PRs, access secrets, modify deployments

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: code-review-agent
  namespace: development
rules:
# Can read source code (via git integration)
- apiGroups: [""]
  resources: ["configmaps"]
  resourceNames: ["repo-access-readonly"]
  verbs: ["get"]
# Cannot access secrets, deployments, or any other resource
# Implicit deny: everything not listed is forbidden

• Action-level permissions: Not just "can access the database" but "can SELECT from these specific tables with these specific columns." Read access doesn't imply write access. Production access doesn't imply staging access
• Time-bounded permissions: An agent processing a batch job gets permissions for the duration of the job, not permanently
• Context-bounded permissions: An agent assisting with a specific customer request can access that customer's data — not all customers' data
• Permission escalation requires human approval: If an agent needs permissions beyond its baseline, it must request approval from a human. The approval is logged and time-bounded

Layer 3: Execution Sandboxing

Agents that generate and execute code need sandboxing that limits the blast radius:

• Container isolation: Agent code execution happens in ephemeral containers with read-only filesystems, no network access by default, and resource limits (CPU, memory, time). Think: Kubernetes Job with Pod Security Standards "restricted" profile
• Network segmentation: Agents can only reach the services they're authorised to call. NetworkPolicies enforce this at the infrastructure level — the agent can't bypass them regardless of what the model decides
• File system isolation: Agents read and write to isolated workspace volumes. They cannot access other agents' workspaces, host filesystems, or production data stores unless explicitly permitted
• Execution time limits: Every agent action has a timeout. Runaway agents (infinite loops, unbounded recursion) are killed after the timeout expires

Layer 4: Action Verification and Human-in-the-Loop

Not every action should be fully autonomous. Define tiers based on risk:

• Tier 1 — Fully autonomous: Read operations, analysis, report generation, code suggestions. Low risk. No human approval needed
• Tier 2 — Notify and proceed: Minor modifications, PR creation, non-production deployments. The agent acts and notifies a human. Human can review after the fact
• Tier 3 — Propose and wait: Production changes, data modifications, external API calls with side effects. The agent proposes an action and waits for human approval before executing
• Tier 4 — Human only: Irreversible actions, access to sensitive data, regulatory submissions, customer communications. The agent surfaces information but a human takes the action

# Action tier configuration
action_tiers:
  tier_1_autonomous:
    - read_source_code
    - analyze_logs
    - generate_report
    - search_documentation

  tier_2_notify:
    - create_pull_request
    - post_code_review_comment
    - deploy_to_staging
    - create_jira_ticket

  tier_3_approve:
    - deploy_to_production
    - modify_database_schema
    - call_external_payment_api
    - update_customer_record

  tier_4_human_only:
    - delete_production_data
    - submit_regulatory_report
    - send_customer_email
    - modify_security_policies

Layer 5: Continuous Monitoring and Audit

Every agent action must be observable:

• Action logging: Every API call, database query, file modification, and external request is logged with: agent identity, human delegator, timestamp, input parameters, output summary, and outcome (success/failure/timeout)
• Anomaly detection: Baseline behavioural profiles for each agent (similar to runtime security for containers). Alert when an agent deviates: unusual access patterns, unexpected API calls, abnormal data volumes
• Token/cost monitoring: Track AI compute consumption per agent. Sudden spikes may indicate a compromised agent running unbounded queries or a prompt injection causing repetitive API calls
• Output monitoring: Sample and review agent outputs. Are they accurate? Are they leaking data? Are they producing harmful content? Automated checks plus periodic human review

Layer 6: Kill Switches

The most important control: the ability to stop an agent immediately:

• Per-agent kill switch: Stop a specific agent instance without affecting other agents or services
• Per-model kill switch: If a model version is producing harmful outputs, disable all agents using that model
• Global kill switch: Stop all AI agent activity across the organisation. This sounds extreme, but if a prompt injection attack is spreading through your agent fleet, you need it
• Automatic triggers: Kill switches should fire automatically on specific conditions: budget exceeded, anomaly score above threshold, failed health check, regulatory compliance violation detected

Agentic AI and the EU AI Act

The EU AI Act's requirements map directly to this control plane:

• Article 9 (Risk Management): The action tier system (autonomous → human-only) is a risk management implementation
• Article 13 (Transparency): Action logging and audit trails provide the transparency required for high-risk AI systems
• Article 14 (Human Oversight): Human-in-the-loop tiers and kill switches satisfy the human oversight requirement
• Article 15 (Accuracy, Robustness, Cybersecurity): Sandboxing, least-privilege, and anomaly detection address the cybersecurity requirement

Organisations deploying agentic AI without a control plane aren't just taking a security risk — they're taking a regulatory risk under the AI Act.

Implementation on Kubernetes

Kubernetes provides natural primitives for much of this control plane:

• Agent identity: Kubernetes ServiceAccounts + OIDC federation with your identity provider
• Authorisation: RBAC for Kubernetes resources; OPA/Kyverno for custom policy enforcement
• Sandboxing: Pod Security Standards (restricted), NetworkPolicies (default deny), ResourceQuotas, ephemeral containers
• Monitoring: Falco/Tetragon for runtime behaviour, OpenTelemetry for action tracing, Prometheus for resource metrics
• Kill switches: Scaling Deployments to 0, NetworkPolicy updates, or Pod deletion via Kubernetes API

For the Kubernetes patterns that underpin agent isolation, scheduling, and lifecycle management, see Kubernetes Recipes.

What Open Empower Delivers

We design and implement the security control plane for agentic AI in regulated enterprises:

• Agent identity and RBAC: Per-agent service accounts, least-privilege policies, delegation chains
• Execution sandboxing: Container isolation, network segmentation, filesystem boundaries, time limits
• Human-in-the-loop architecture: Action tier design, approval workflows, notification systems
• Observability: Action logging, anomaly detection, cost monitoring, output review pipelines
• Kill switch infrastructure: Per-agent, per-model, and global kill switches with automatic triggers
• EU AI Act compliance: Control plane mapped to Articles 9, 13, 14, and 15

Agentic AI is powerful. Uncontrolled agentic AI is dangerous. The control plane is the difference. Let's build yours.