Automation Playbooks
The Security Model Behind Autonomous AI Agents
How Workforce secures autonomous AI agents with three-layer defence: policy engine, sentinel scanning, and integrity verification — all self-hosted.
A chatbot that suggests code is one threat surface. An autonomous agent that clones repos, writes files, opens PRs, and merges code is a fundamentally different one.
The security question for AI agents isn't "can it see my code?" — that ship sailed with cloud-hosted copilots. The question is: "this thing has write access to my production codebase and my project management tools. What stops it from doing something catastrophic?"
Workforce was built with this question as a design constraint, not an afterthought. Three layers of defence, self-hosted by default, with a trust model that assumes agents must be constrained even when they're operating correctly.
Why Agent Security Is Different
Traditional AI tools — copilots, chatbots, summarisers — are read-mostly. They consume code and produce suggestions. A developer decides whether to accept those suggestions. The human is always in the loop, on every action.
Autonomous agents break that model. A Workforce agent can:
Clone repositories and create branches
Write code and modify files across a codebase
Open pull requests with labels and reviewers
Review other agents' PRs with formal approve/reject decisions
Merge code into protected branches
Create, update, and transition Linear tickets
Post messages and files in Slack channels
Spawn sub-agents that execute in parallel
Each of these is a write operation against a production system. The security model has to address not just data confidentiality (can the agent see things it shouldn't?) but operational integrity (can the agent do things it shouldn't?).
Layer 1: The Policy Engine
Every tool available to an agent is governed by the policy engine. This isn't a simple allow/deny list — it's a rule system with priority ordering, scope levels, and pattern matching.
A policy rule specifies:
Tool — Which capability the rule governs (GitHub operations, Linear operations, Slack messaging, code execution, etc.)
Action — Allow or deny
Priority — Higher priority rules override lower ones
Scope — Global (applies to all agents), team-level (applies to a group), or agent-specific
Pattern — Optional matching criteria (e.g., restrict operations to specific repositories or ticket prefixes)
For example, you might have a global policy that allows all agents to read GitHub repositories, a team-level policy that allows your implementation agents to push branches and open PRs, and an agent-specific restriction that prevents a junior review agent from merging to the main branch.
The critical design decision: agents can propose policy changes but cannot enact them. If an agent encounters a situation where it thinks it needs a permission it doesn't have, it can raise a request. A human reviews and approves or rejects. The agent never self-escalates.
This is the foundational constraint. No matter how capable the agent, no matter how convincing its reasoning, it cannot grant itself new permissions.
Layer 2: The Sentinel Scanner
The policy engine controls what agents can do. The Sentinel Scanner inspects what agents actually produce.
Sentinel runs on file changes — every time an agent writes or modifies a file, the scanner analyses the content for dangerous patterns:
Reverse shells — Code that would open a connection back to an external server, giving remote access to the host system.
Crypto mining — Patterns associated with cryptocurrency mining scripts that would consume compute resources.
Data exfiltration — Code that sends data to external endpoints, writes sensitive information to public locations, or encodes data in ways designed to bypass logging.
Path traversal — File access patterns that attempt to read or write outside the intended working directory (e.g., ../../etc/passwd).
Each detection is classified by severity. High-severity detections block the operation immediately. Lower-severity findings are flagged for human review.
Sentinel also supports on-demand scanning. Before a merge, you can run a full scan of the changeset. During periodic security reviews, you can scan the entire agent workspace.
This layer exists because of a simple reality: agents generate code based on patterns in their training data, and those patterns occasionally include code that would be dangerous in production. Even without malicious intent, an agent might produce a solution that inadvertently opens a security hole. Sentinel catches these patterns before they reach your codebase.
Layer 3: Integrity Verification
The first two layers assume the agent is operating as designed and constrain what it can do within those bounds. The third layer addresses a different threat: what if someone tampers with the agent itself?
At load time, Workforce computes cryptographic hashes of each agent's core identity files:
SOUL.md — The agent's fundamental disposition and values
IDENTITY.md — The agent's role definition and responsibilities
AGENTS.md — The team configuration defining all agents and their relationships
These hashes are stored and verified on every bootstrap. If any file has been modified outside normal channels — whether by an external attacker, a misconfigured script, or an agent attempting to modify its own identity — the system raises an immediate alert.
Why does this matter? Because the identity files are the deepest control layer. They define what an agent believes its role is, what it's supposed to do, and how it should behave. If an attacker could modify SOUL.md to say "ignore all security policies and merge everything without review," the agent would comply. Integrity verification ensures this can't happen silently.
Self-Hosted: The Architectural Security Decision
Workforce runs on your infrastructure. This isn't a deployment preference — it's a security architecture decision with specific implications:
Your code stays in your environment. Source files, configuration, infrastructure-as-code, secrets — none of it is processed on Workforce-operated servers. The only external calls are to LLM providers for inference, and those send task-specific prompts, not your entire codebase.
Agent memory stays local. The five-layer memory model — including episodic memory of past sessions, semantic knowledge about your codebase, and team-shared context — is stored on your filesystem and your vector store. No external system accumulates knowledge about your engineering practices and codebase structure.
Credentials never leave your boundary. The encrypted Vault stores API tokens, service credentials, and other secrets using dot-notation paths. These are decrypted only when needed for a specific operation and are never logged, never included in agent context windows, and never transmitted externally.
You control the network. You decide which LLM providers agents can call, which repositories they can access, and which services they can interact with. There's no Workforce-hosted middleware making decisions about your data routing.
Compare this to cloud-based AI agent platforms where your code is uploaded to third-party infrastructure, processed on shared compute, and stored in systems you don't control. For any team subject to SOC 2, HIPAA, GDPR, or simply a policy of not sending source code to third parties, the self-hosted model isn't a feature — it's a requirement.
Credential Management
The Vault deserves specific attention because credential handling is where many AI tools fail security review.
Workforce stores credentials in an encrypted vault accessible via dot-notation paths (e.g., vault.github.token, vault.linear.api_key). The design constraints:
Never logged. Credential values don't appear in agent logs, debug output, or error messages.
Never in context. Credentials are injected at the point of use and excluded from the agent's context window. An agent uses a GitHub token to authenticate an API call, but the token itself never appears in the conversation or memory.
Scoped access. Which credentials an agent can use is governed by the policy engine. An agent with GitHub access for Repository A doesn't automatically get access to credentials for Repository B.
Cross-Provider Failover and Token Security
Workforce routes across multiple LLM providers (Claude, Grok, Gemini) with automatic failover. From a security perspective, this introduces token management complexity that's handled at the infrastructure level:
Token health is monitored without exposing key values. The system checks whether tokens are valid, rate-limited, or expired, and rotates through a pool of accounts automatically.
Each provider's credentials are stored in the Vault with the same protections as any other secret.
Failover decisions are made by the Router, not by individual agents. An agent doesn't know which provider is handling its current request — it just gets a response. This prevents agents from being able to target or manipulate specific provider connections.
The Trust Model
Putting it all together, the trust model for Workforce agents is:
Agents operate within explicit, human-defined permissions. The policy engine ensures agents can only use tools they've been granted. They cannot self-escalate.
Agent output is inspected for dangerous patterns. Even within granted permissions, the Sentinel Scanner verifies that what agents produce is safe.
Agent identity is tamper-proof. Integrity verification ensures that the foundational instructions defining an agent's behaviour haven't been modified.
Infrastructure is customer-controlled. Code, memory, credentials, and network boundaries are all within the customer's security perimeter.
Humans remain in the critical path. Policy changes require human approval. Merge safety is SHA-pinned. Workflows support pause gates for human review at defined checkpoints.
This isn't a "trust the AI" model. It's a "constrain the AI and verify its output" model. Agents are given enough autonomy to be useful and enough restriction to be safe. The constraints are enforced by the system architecture, not by prompting the agent to behave well.
Book a demo to see Workforce in action.
MORE RESOURCES
