Skip to content
Defiant

Compliance & Security

Defiant is built for teams that operate in regulated environments. This page covers Defiant’s own security posture, the compliance controls it enforces on projects, and the audit artifacts it produces.

Defiant’s security posture

What Defiant stores locally

Defiant stores all sprint data locally:

  • ~/.defiant/credentials.json — API keys, chmod 600
  • ~/.defiant/events.db — append-only SQLite event log
  • ~/.defiant/worktrees/ — ephemeral git worktrees (cleaned after sprint)
  • ~/.defiant/logs/ — agent turn logs

No code, no credentials, and no sprint data are sent to Defiant’s servers. The only outbound network calls are:

  • To the Anthropic API (inference calls with your prompts and code)
  • To the Supabase API (your own Supabase instance — sprint metadata, not code)
  • To GitHub (PR creation, status checks)
  • To your configured integrations (Sentry, PostHog, etc.)

Credential storage

Credentials are stored in ~/.defiant/credentials.json with 600 permissions. They are never committed to git. The defiant init wizard and defiant config set commands manage this file.

For team environments, credentials should be injected via environment variables rather than stored in the file:

Terminal window
export ANTHROPIC_API_KEY=sk-ant-...
export GITHUB_TOKEN=ghp_...
defiant watch start

Anthropic API usage

Defiant sends code from your working tree to the Anthropic API as part of agent prompts. Review Anthropic’s data handling policies and enterprise data agreements if this is a concern. For air-gapped environments, a self-hosted LLM backend is on the roadmap.

SOC 2 Type II

Defiant supports SOC 2 Type II compliance for projects that need it. The relevant controls:

CC6: Logical access controls

The Supabase-backed REST API enforces JWT authentication on all endpoints. Row-level security ensures users can only access their own projects and sprints (mandate_44).

-- Applied by the Architect to all user-data tables
ALTER TABLE sprints ENABLE ROW LEVEL SECURITY;
CREATE POLICY "Users can only see their own sprints"
  ON sprints FOR ALL
  USING (auth.uid() = user_id);

CC7: System operations — logging

All sprint events are written to the append-only event log (mandate_47). Log entries include:

  • Timestamp (UTC, millisecond precision)
  • Actor (agent ID or user ID)
  • Action type
  • Resource ID
  • Before/after state (for state transitions)
Terminal window
# Export event log for SOC 2 audit
defiant events export \
  --format jsonl \
  --since 2026-01-01 \
  --before 2026-04-01 \
  > q1-2026-events.jsonl

CC8: Change management

Every code change produced by Defiant goes through the mandate check + Reviewer + Guardian pipeline before merging. The completion certificate (mandate_12) proves this occurred for each PR.

GDPR

Article 17 — Right to erasure

Defiant enforces Art. 17 via mandate_20. Any project that stores personal data must implement a deletion endpoint:

// Generated by Builder for GDPR-compliant projects
async function deleteUserData(userId: string): Promise<void> {
  await db.transaction(async (trx) => {
    // Delete from all tables containing personal data
    await trx.from('user_profiles').where({ user_id: userId }).delete();
    await trx.from('user_preferences').where({ user_id: userId }).delete();
    await trx.from('activity_events').where({ user_id: userId }).delete();


    // Log the deletion for audit trail
    await trx.from('gdpr_deletion_log').insert({
      user_id: userId,
      deleted_at: new Date().toISOString(),
      deleted_by: 'user-request',
    });
  });
}

The Guardian checks that deletion is complete (no orphaned rows) and that the deletion is logged.

Article 20 — Right to data portability

Mandate_21 requires a data export endpoint:

// Generated by Builder for GDPR-compliant projects
async function exportUserData(userId: string): Promise<UserDataExport> {
  const [profile, preferences, activity] = await Promise.all([
    db.from('user_profiles').where({ user_id: userId }).select('*'),
    db.from('user_preferences').where({ user_id: userId }).select('*'),
    db.from('activity_events').where({ user_id: userId }).select('*'),
  ]);


  return {
    exportedAt: new Date().toISOString(),
    userId,
    data: { profile, preferences, activity },
    format: 'json',
  };
}

HIPAA

For Healthcare vertical projects, Defiant enforces the HIPAA Security Rule via the healthcare mandate pack (19 mandates). Key controls:

PHI identification

The Counselor and Guardian agents look for these field names as PHI indicators:

diagnosis, condition, medication, prescription, lab_result, test_result,
clinical_note, doctor_note, icd_code, cpt_code, date_of_birth, dob,
ssn, social_security, mrn, medical_record, insurance_id, npi

Any table or API response containing these fields is subject to HIPAA mandates.

Encryption requirements

# mandate_h1 enforces:
at_rest:
  algorithm: AES-256-GCM
  key_management: environment variable or KMS — never hardcoded


in_transit:
  minimum_tls: 1.2
  cipher_preference: ECDHE-RSA-AES256-GCM-SHA384

Audit trail format

Every PHI access is logged with:

interface HIPAAAuditEntry {
  id: string;
  userId: string;           // who accessed
  patientId: string;        // whose data
  resourceType: string;     // 'diagnosis' | 'lab_result' | ...
  resourceId: string;
  action: 'read' | 'write' | 'delete';
  purpose: string;          // required: why was this accessed?
  timestamp: string;        // ISO 8601 UTC
  ipAddress: string;
  sessionId: string;
}
Terminal window
# Export HIPAA audit log
defiant events export \
  --type hipaa_phi_access \
  --format jsonl \
  --since 2026-01-01 \
  > hipaa-audit-q1-2026.jsonl

SSO (SAML / OIDC)

B2B SaaS and Enterprise projects use mandate_b2, which requires SSO support.

Supabase + SAML 2.0

Defiant projects on Supabase can use the built-in SAML 2.0 provider:

// Generated by Ambassador for SSO-enabled projects
const { data, error } = await supabase.auth.signInWithSSO({
  domain: 'yourorg.com',
  options: {
    redirectTo: `${window.location.origin}/auth/callback`,
  },
});

OIDC

const { data, error } = await supabase.auth.signInWithOAuth({
  provider: 'google',     // or 'azure', 'github', 'okta' (custom)
  options: {
    scopes: 'openid email profile',
    redirectTo: `${window.location.origin}/auth/callback`,
  },
});

SCIM provisioning

Mandate_b12 requires SCIM provisioning for enterprise B2B SaaS. The Ambassador agent generates a SCIM 2.0 endpoint when this mandate is active:

POST /scim/v2/Users           — provision user
GET  /scim/v2/Users/:id       — get user
PATCH /scim/v2/Users/:id      — update user
DELETE /scim/v2/Users/:id     — deprovision user
GET  /scim/v2/Groups          — list groups

Compliance audit export

Export all compliance-relevant data for an audit period:

Terminal window
defiant compliance export \
  --project proj_01hw... \
  --since 2026-01-01 \
  --before 2026-04-01 \
  --format zip \
  --output q1-2026-compliance.zip

The ZIP contains:

q1-2026-compliance/
  events.jsonl                   # full event log
  mandate-checks.jsonl           # all mandate check results
  completion-certificates/       # one JSON per sprint
  sprint-summaries.jsonl         # one summary per sprint
  agent-dispatches.jsonl         # all agent dispatch records
  inbox-resolutions.jsonl        # all human decisions
  hipaa-audit.jsonl              # PHI access log (Healthcare only)
  gdpr-deletions.jsonl           # Art. 17 deletion log (if applicable)