Risks Security and Governance

Risks, Security & Governance

Status: Complete · The "things to consider" before you bet a real product — especially someone else's data — on solo AI‑native delivery.

Collapsing the 12 layers removes hand‑off latency. It does not remove the concerns those layers represented. Security review, compliance, and accountability didn't disappear — they concentrated onto you. This page is how you carry that weight deliberately.

---

AI‑specific risks

These are new failure modes the legacy process never had to think about:

Risk	What it looks like	Mitigation
Hallucinated correctness	Code that looks right, reads right, and is subtly wrong	Fresh‑context adversarial verification (Guardian); "refute, don't confirm"
Insecure generated code	Missing authZ, injection‑prone queries, weak crypto defaults	Security checks in the spec + a dedicated security‑lens review pass
Prompt injection	Untrusted input (docs, web content, user data) hijacks an agent's instructions	Never let untrusted content carry authority; isolate tool access; treat agent output as untrusted until verified
Silent scope creep	Agent "helpfully" changes things you didn't ask for	Diff‑driven review; flag unrequested changes
Dependency risk	Agent adds an unvetted or malicious package	Review every dependency it introduces; pin versions
IP / license ambiguity	Generated code of uncertain provenance or license	Keep an audit trail; review for verbatim third‑party snippets where it matters

---

Security defaults (non‑negotiable)

• Secrets live in environment variables or a secret store — never in code, commits, or prompts. Assume anything pasted into an agent could leak.
• Input validation & sanitization on every external boundary. Generated code is not secure by default.
• AuthZ in the spec. Write who can do what explicitly and make the Guardian test it. Never assume the agent added permission checks.
• Least privilege for agent tooling and service credentials. An agent with prod‑delete rights is an incident waiting to happen.
• Dependency hygiene. Vet, pin, and update deliberately.

→ Quick‑reference table in Best Practices › Security.

---

Data privacy & compliance

Consider	Questions to answer before shipping
PII / sensitive data	What personal data flows through the system? Is it minimized, encrypted, and access‑controlled?
Data residency	Does your Zero‑Ops platform store data in a region your jurisdiction/customer requires? Verify before committing.
Regulatory regime	GDPR, HIPAA, SOC 2, PCI‑DSS? Some mandate controls (independent review, change sign‑off) you cannot collapse — see When NOT to Use SAE.
Sending data to model providers	What leaves your boundary in prompts/telemetry? Is that contractually and legally allowed for this data class?
Right to deletion / retention	Can you actually delete a user's data on request across every managed service?

In regulated domains, apply the SAE inside the mandated gates to remove their latency — keep the controls, kill the queue.

---

Governance for a team of one

The hardest governance problem in SAE isn't bureaucracy — it's that one person is the entire control structure. Build the checks in deliberately:

• Human‑in‑the‑loop gates. Auth, payments, data deletion, schema drops, and external sends are never auto‑applied. The agent proposes; you decide. Automate the reversible; gate the irreversible.
• The spec is your audit trail. Because every change flows through the spec, specs/ + git history is your change log. Keep it honest and it answers "why does the system do this?" for auditors and your future self alike.
• Bus‑factor mitigation. N = 1 is a single point of failure. The succession plan is a current, authoritative spec folder — anyone competent can pick up specs/ and continue. Document accordingly.
• Accountability. You own every line, including the ones you didn't type. "The AI wrote it" is not a defense. If you can't evaluate the output, you can't ship it — bring in a human expert or don't.

---

Cost & lock‑in

Consider	Guidance
Token spend	Match model tier to entropy; don't burn frontier tokens on trivial edits. Track cost per change.
Platform spend at scale	Managed/serverless pricing can surprise you as usage grows — model it before you depend on it.
Vendor lock‑in	Favour standard exit formats (plain Postgres you can pg_dump, portable components). Zero‑Ops should never become zero‑leverage.
Exit plan	For each critical dependency, know how you'd migrate off it. If you can't answer, that's concentration risk.

---

A pre‑ship governance checklist

Run this before anything touching real users or data goes live:

• AuthZ rules are spec'd and tested
• No secrets in code, commits, or prompts
• External inputs validated; failure modes handled
• PII minimized, encrypted, region‑appropriate
• Irreversible actions sit behind a human gate
• Dependencies reviewed and pinned
• Spec is current (drift = 0) and serves as the audit trail
• Rollback / feature‑flag path exists
• Regulatory controls for the domain are intact, not collapsed

---

Reality check. This page can read as fear, uncertainty, and doubt against a framework that sells speed. It isn't — it's the price of admission for speed you can trust. The SAE's velocity is only an advantage if what you ship is correct, secure, and defensible. A breach, a compliance failure, or a data‑loss incident erases months of "10x" in a single afternoon. Go fast on the reversible; go careful on the rest.

---

See also: When NOT to Use SAE · Best Practices · Module 4: The Lean SAE Tech Stack.