Protecting an AI Agent from unauthorized operations

· 2 min read

Artificial Intelligence Security

I’ve been researching and reviewing what can be done to better protect against improper agentic actions.  The list of mitigations may be partial, but it’s an initial engineering design for protecting ourselves from the threat of bad internal agentic actor.  

Running a Locked‑Down Secure Linux for Agentic Containers

For containers running on a host, point 4 is especially critical.  

  1. Minified hardened base image
    Always use a minified container as your starting base with a non‑root user, dropped capabilities, and a read‑only root filesystem.
  2. SELinux in enforcing mode
    Implement SELinux in enforcing mode to restrict what the agent can touch.
  3. seccomp least‑privilege syscall profiles
    Implement seccomp to enforce least‑privilege profiles for kernel access.
  4. Virtualized kernel boundary (Kata / gVisor / Firecracker)
    Use Kata or similar tooling (gVisor, Firecracker) to provide a virtualized kernel boundary and mitigate kernel escape attacks.

Agentic Architecture recommendations for containers

  1. Network isolation—deny by default
    Isolate the network—deny by default, and allowlist only what is necessary for the workload. Never allow access to CI/CD, artifact registries, metadata endpoints, and internal APIs.
  2. IAM restrictions with human‑in‑the‑loop on a separate broker
    Deny everything by default. Assign read‑only where necessary and require human‑owned credentials for any changes. Run human approval required actions on a separate tiny execution broker. Use short‑lived, scoped tokens derived from human approvals. Agents must never hold privileged or long‑lived IAM roles directly.
  3. Cryptographic provenance
    Ensure the integrity and authenticity of the agent via a cryptographically signed bill of materials (CBOM/SBOM) prior to execution.  

Separate execution of human‑approved actions from the agent

Any human interaction tokens should be processed in a separate isolated process that:

  1. Verifies the agent identity and workflow identifier
  2. Verifies the execution request
  3. Requires human approval
  4. Obtains a short‑lived scoped token for the action
  5. Executes the action deterministically using the identity of the human approver
  6. Logs the action and binds it to the human approver and human risk owner
  7. Invalidates the token
  8. Wipes the token and execution details from memory
  9. Replies with a simple success/fail back to the agent
  10. And in the event of failure, log the fail reason rather than returning it to the agent

Execution Failure Evaluation

  1. Any failure investigation must be done by a human reviewing the logs
  2. Use human judgment to choose whether to allow the agent model to learn from the execution failure