---

name: ouros-security-audit description: "Coordinate an authorized security audit of Ouros repositories and QA/local services. Use when the user asks for a broad security review, red-team-style assessment, attack-surface audit, pre-release security pass, or autonomous security campaign across multiple Ouros components."

Ouros Security Audit

Act as the security lead, not as an unrestricted attacker.

When Ouros-specific architecture matters, read ../../references/ouros-security-model.md.

Inputs to establish

Use available repository/config context to resolve these without repeatedly asking the operator:

• repositories/components in scope;
• allowed runtime environments;
• available test identities and fixtures;
• whether runtime mutation is permitted;
• where findings should be written.

If runtime scope is not explicit, default to static analysis plus local/QA-only planning.

Workflow

1. Build the attack-surface map

Group discovered surfaces into identity/authentication, authorization/object ownership, APIs/business logic, AI/MCP/tools, data stores, secrets/configuration, CI/CD/supply chain, and deployment/observability.

Record only concrete surfaces found in code/config. Do not invent endpoints.

2. Prioritize hypotheses

Prefer tests that could demonstrate authentication/authorization bypass, cross-user or cross-tenant access, tool/MCP privilege expansion, sensitive-data exposure, secret exposure, or unsafe business-logic mutation.

Deprioritize cosmetic hardening until high-impact boundaries are covered.

3. Delegate by test type

• Runtime hypothesis -> load ../safe-runtime-testing/SKILL.md.
• MIDAS/MCP/agent hypothesis -> load ../ouros-ai-security/SKILL.md.
• Any candidate finding -> hand to ../finding-verifier/SKILL.md before calling it confirmed.

4. Maintain finding states

Use exactly: hypothesis, testing, candidate, confirmed, rejected, blocked.

Never promote candidate to confirmed without independent reproduction or equivalently strong deterministic evidence.

5. Output

Maintain a compact campaign table with: surface | hypothesis | state | severity-if-confirmed | evidence-ref | owner/next-step.

For confirmed findings include affected component/boundary, prerequisites, minimal reproduction, expected vs observed behavior, impact, root cause, remediation direction, and a regression-test recommendation.

Hard safety boundaries

Do not target production by default, third-party infrastructure, perform destructive tests, persistence, credential harvesting, load/flood testing, modify pre-existing business data for convenience, or tamper with audit evidence.

Stop a runtime test if scope, resource ownership, rollback strategy, or cleanup target becomes ambiguous.