Security
Security is architecture, not afterthought
Giving AI agents access to your codebase, deployments, and communication channels requires a security model that is rigorous, layered, and auditable. CodeSpar's security is built into the architecture from day one.
Defense in Depth
10 layers. Every message passes through all of them.
Security is not a single gate — it is a pipeline. Every incoming message traverses all 10 layers before reaching an agent. Every outgoing action traverses them again in reverse.
Message Filter
First line of defense. Filters incoming messages before they reach any agent. Rate limiting, content validation, spam detection, and blocklist enforcement. Drops malformed or suspicious messages before parsing.
Channel Configuration
Per-channel security policies. Define which commands are allowed per channel, which users can invoke agents, and what autonomy level applies. WhatsApp groups can have different rules than Slack workspaces.
Identity Resolution
Maps channel-specific user identities to unified CodeSpar identities. Verifies that the user sending a message is who they claim to be. Supports SSO, OAuth, and channel-native auth.
RBAC (6 Roles)
Role-based access control with six hierarchical roles: Viewer, Developer, Maintainer, Admin, Owner, and System. Each role has a specific permission set. Roles are per-project, not global.
ABAC Policies
Attribute-based access control for fine-grained rules. Policies can reference time of day, branch name, file path, change size, and risk score. Example: 'Only allow auto-merge on main if change is < 50 lines.'
Agent Sandbox
Agents run in isolated contexts with limited system prompt scope. Each agent only sees the data it needs. Project Agents cannot access other projects. Task Agents cannot access the network.
Prompt Injection Defense
Multi-layer prompt injection detection: input sanitization, instruction hierarchy enforcement, output validation, and canary token monitoring. LLM outputs are never trusted as commands.
Execution Sandbox
Docker containers with no network, memory limits, CPU quotas, read-only filesystem, and time limits. Task Agents cannot escape their container. Failed containers are destroyed, not restarted.
Output Validation
Every agent output is validated before delivery. Code changes are scanned for secrets, credentials, and security anti-patterns. Responses are checked for data leakage and PII exposure.
Audit Trail
Every action is logged immutably: who requested it, which agent executed it, what changed, and whether it was approved. Audit logs cannot be modified or deleted. Retention configurable per org.
Permission Model
Agents inherit permissions. They never own them.
This is the core security principle. When a user asks an agent to perform an action, the agent executes with that user's permissions — not its own. If the user can't deploy to production, the agent can't deploy to production on their behalf.
Invoked Actions
When a user explicitly asks an agent to do something (e.g., "@codespar deploy to staging"), the action runs with that user's role and permissions. The agent is a tool, not an actor.
Autonomous Actions
When an agent acts on its own (e.g., auto-creating a PR after CI failure), it uses a restricted system role bounded by the project's autonomy level. High-risk autonomous actions always require human approval.
Agents can never escalate their own permissions, modify their own autonomy level, or approve their own actions. These operations always require a human with the Owner role.
RBAC
Six roles. Explicit permission matrix.
Roles are hierarchical and per-project. A user can be an Owner of one project and a Developer on another. Permissions are additive — each role includes all permissions of the roles below it.
| Role | View Status | Query Agent | Run Tasks | Review PRs | Deploy | Manage Config | Manage Users | Kill Switch |
|---|---|---|---|---|---|---|---|---|
| Viewer | ||||||||
| Developer | ||||||||
| Maintainer | ||||||||
| Admin | ||||||||
| Owner | ||||||||
| System |
Confirmation Strategy
Verification proportional to impact
Not all actions need the same confirmation. Low-risk queries execute instantly. Critical operations require multi-factor approval. The confirmation UX adapts to each channel's native capabilities.
| Risk | Examples | Slack | Telegram | Discord | CLI | |
|---|---|---|---|---|---|---|
| Low | Status queries, log lookups, codebase questions | Auto-execute | Auto-execute | Auto-execute | Auto-execute | Auto-execute |
| Medium | Create branch, open PR, run tests | Inline confirm | Button confirm | Inline KB | Reaction confirm | Y/N prompt |
| High | Merge to main, deploy to staging, modify CI config | Reply with code | Modal + 2FA | Reply with code | DM confirm | Explicit flag |
| Critical | Deploy to prod, delete resources, modify security config | Blocked | Modal + 2FA + admin | Blocked | Blocked | Admin flag + confirm |
Threat Model
12 threats. Documented mitigations.
We publish our threat model openly. Every identified threat has a probability assessment and a concrete mitigation strategy. This is a living document updated with every architecture change.
| ID | Threat | Probability | Mitigation |
|---|---|---|---|
| T01 | Prompt injection via chat message | High | Input sanitization, instruction hierarchy, canary tokens, output validation |
| T02 | Unauthorized command execution | High | RBAC enforcement at message router, identity verification before any action |
| T03 | Container escape | Low | Docker rootless mode, seccomp profiles, read-only filesystem, no network |
| T04 | Credential theft from repo | Medium | Secret scanning on all agent outputs, no .env file access, vault integration |
| T05 | Supply chain attack via dependencies | Medium | Lockfile pinning, Dependabot, signed commits, Review Agent analysis |
| T06 | Data exfiltration through agent responses | Medium | Output validation layer, PII detection, channel-specific redaction rules |
| T07 | Denial of service via task flooding | Medium | Per-user rate limits, queue depth limits, task timeout enforcement |
| T08 | Cross-project data leakage | Low | Project-level isolation, separate agent contexts, no shared memory |
| T09 | Malicious webhook spoofing | Medium | Webhook signature verification, IP allowlisting, replay protection |
| T10 | Privilege escalation via role manipulation | Low | Role changes require Owner role, audit logged, cooldown period |
| T11 | Audit log tampering | Low | Append-only log store, cryptographic chaining, external backup |
| T12 | WhatsApp session hijacking | Medium | Session encryption at rest, automatic re-auth, anomaly detection |
Kill Switch
Emergency shutdown in seconds
Any user with the Owner role can trigger a kill switch from any channel. It stops all agents, terminates running tasks, logs the event, and alerts the organization. No waiting. No graceful degradation. Immediate halt.
The kill switch is a hard stop, not a pause. After triggering it, agents must be explicitly restarted. This prevents accidental re-activation and gives the team time to investigate whatever triggered the emergency.
Kill switch events are prominently logged and cannot be deleted. They include the initiator, timestamp, reason (if provided), and the list of agents that were terminated.
Security you can audit yourself
The full threat model, security architecture, and audit system are documented and open source. Read the code. Run the tests. Verify every claim.