Model Card — Securie Autonomous Security Engineer
Version 1.0 · Effective 2026-04-22 · AI governance disclosure
Intended use
Analyze application source code + configuration + dependencies for security-relevant defects. Emit JSON findings conforming to the Securie Finding schema. Propose code-level fixes (GitHub Suggested-Change format). Not intended for general-purpose code generation, chat, or content moderation.
Inference controls
| Control | Role | Evidence |
|---|---|---|
| Local-first triage | Low-risk classification, secret screening, and evidence normalization. | Policy version, prompt-template hash, and replay metadata. |
| Specialist reasoning | Framework-specific analysis for auth, data access, AI features, and supply-chain paths. | Specialist id, run id, finding proof, and fix-verification result. |
| Bounded escalation | Higher-cost review only when sandbox evidence or policy requires deeper reasoning. | Escalation reason, cost envelope, and approval policy. |
| Output safety | Policy checks for generated remediation, exploit proof, and customer-facing report text. | Safety result and blocked-output reason when applicable. |
Securie reviews provider reliability, licensing, residency, retention posture, and validation results before production routing changes. Customer evidence bundles record the policy and control path used for each verified review.
Training data
Securie does not use customer source code to train, fine-tune, or distill any model — on any plan, including Enterprise. Securie ships stock-weight OSS models and uses them exactly as published; there is no fine-tuning, LoRA, or model-training pipeline. Prompts may be grounded with public security references such as OWASP, CWE, CVE records, public disclosures, and vendor documentation.
Product telemetry may store Securie-generated remediation outcomes, finding classes, and aggregate effectiveness signals. It does not store customer source code as training data of any kind.
This posture is published as a signed training-data attestation at /legal/training-data-attestation and bound contractually by the Data Processing Addendum §4. Enterprise deployments can additionally define stricter residency, retention, and provider controls in the signed order form.
Known limitations
- Coverage varies by stack. The strongest coverage is currently TypeScript/JavaScript application security, Supabase RLS, auth/authz, secrets, AI-feature abuse, and supply-chain risk.
- Runtime proof requires a runnable path. Sandbox validation depends on enough build, dependency, and environment context to reproduce the affected code path.
- False-positive control. Verified findings are preferred; unreproducible findings are downgraded or suppressed when policy requires proof before blocking.
- AI output non-determinism. Outputs can vary, so every finding carries confidence, evidence, and verification status.
Safety guardrails
- Input/output policy checks. Inference calls pass through safety and data-handling controls on prompt and response.
- Scoped offensive testing. Exploit proof and pentest workflows are constrained to authorized customer assets and sandboxed environments.
- Cost firewall. Per-tenant usage envelopes and escalation-ratio caps are enforced before dispatch.
- Prove-don't-flag. When Firecracker sandbox is attached, high-severity findings can be suppressed unless the exploit reproduces.
Human oversight
Every auto-patch is surfaced as a GitHub Suggested-Change — the maintainer must click "Commit suggestion" to merge. Securie never auto-merges. Privileged overrides (deploy-gate bypass, refund issuance) require a human-held admin token.
Governance posture
Securie maintains technical documentation, logging, risk management, human-oversight controls, and customer evidence bundles for AI-assisted security review. Regulatory classification is reviewed as product use, geography, and applicable law evolve.
Contact
Questions: ai-governance@securie.ai