Security

Headmaster is designed around least-privilege access, human approval gates, auditable agent runs, and clear deployment boundaries. This page describes the security model and the evidence teams should collect during rollout.

Security model

Workspace isolation

Each organization should run with isolated workspace configuration, separate credentials, and scoped agent memory.

Human approval gates

Sensitive actions such as external communications, data writes, exports, and financial operations can pause until an authorized approver signs off.

Run history

Runs retain prompts, tool calls, approvals, results, and operator interventions so teams can reconstruct what happened locally.

Permissions

Least privilege

Agents and plugins should receive only the tools, channels, files, and APIs required for their assigned workflows.

Role separation

Recommended roles are viewer, operator, approver, and administrator. Approvers should be distinct from the agent identity performing the work.

Credential handling

Store API keys and integration credentials in managed secrets storage. Rotate credentials on a regular schedule and after personnel or vendor changes.

Data handling

Evidence to maintain

Keep deployment diagrams, data-flow maps, access reviews, approval policy records, incident-response procedures, and run-audit samples.

Customer-controlled deployment

Headmaster runs locally by default. For regulated environments, keep it on infrastructure you control and align retention, backup, and logging with internal policy.

Vendor review

Review model providers, messaging platforms, storage systems, and plugins before enabling them in production workflows.

Production checklist

• Define approval gates before production access.
• Restrict integrations to required scopes.
• Enable run logging and retention policies.
• Review plugin permissions before installation.
• Document incident response and rollback procedures.