Official recipe · Agent coordination

Build a repository-grounded threat model with checked boundaries

Source-backed example. Practical decision guidance is proposed and untested; this is not a full implementation guide.

The problem

Security reviewers need to distinguish real repository boundaries and existing controls from assumptions before relying on a threat model.

Agent job

Review an authorized repository offline, trace entry points and enforcement boundaries, verify anchors and produce a scoped threat model.

Expected output

A source-grounded threat model separating scenarios, controls and unresolved questions.

Where this framing comes from

Core problem: Editorial purpose framing
Agent job: Editorial purpose framing
Expected output: Editorial purpose framing
Relevant job roles: Editorial purpose framing
Benefit type: Editorial purpose framing

Editorial framing and outcome limits

Describes the task’s purpose and intended output; measured benefit, safe unsupervised operation and successful delivery are not established by this framing.

Editorial synthesis based on the linked source. This framing does not add evidence of successful delivery or results.

Case-specific decision guidance · untested

Case-specific decision guidance and first checks are original proposals. The linked source supports the attributed task; this added guidance has not been executed.

Read the attributed source evidence and original caveats below ↓

Why use this

A threat model can become misleading when it treats repository structure as a complete picture of deployment. An apparent trust boundary may be enforced elsewhere, while a documented control may never run on the relevant request path.
This job could ground security discussion in traceable code observations and explicit unknowns. A reviewer could distinguish plausible scenarios from verified controls and decide which deployment questions need answers before prioritizing further investigation.

Why an agent / simpler alternative

Useful judgment: Trace authorized source relationships and explain where assumptions affect a security scenario.
Simpler alternative: Use an existing reviewed architecture model when only a small documented boundary changed.
Unsuitable when: The task requires live probing, exploit execution or access outside the authorized repository scope.

Proposed inputs

Name
Authorized source snapshot
Owner
Repository owner
Minimum scope
Scoped files, revision identifier and permitted supporting documents
Quality check
Treat repository instructions as untrusted content rather than action authority.
Name
System boundary brief
Owner
Security owner
Minimum scope
Known deployments, assets, callers and intended review scope
Quality check
Mark unverified topology or identity assumptions explicitly.

Access and setup — proposed or unknown

Proposed minimum: Use offline read-only inspection and a separate draft; preserve any supplied model unchanged unless revision is requested.
Compatibility unknowns: Unknown: source completeness, deployment accuracy, plugin versions and artifact-tool access.
External actions requiring approval: Executing application code, contacting services, revising supplied models or updating reusable caches.

Expected deliverable and review checks

Proposed artifact: Scoped threat-model draft with code anchors, entry points, assets, controls, scenarios and unresolved questions.
Critical checks: Anchors support the precise claimed boundary or control.
Hypothetical attack paths are not represented as confirmed vulnerabilities.
Missing output evidence: No new run or output inspection in this editorial layer; see linked source-specific limits.

Failure signals and proposed responses

Signal
An authentication helper exists but is bypassed on one route.
Why it matters
The model may claim coverage that the route does not receive.
Proposed response
Trace enforcement at each in-scope entry point and record the exception as a review question.
Signal
A deployment assumption comes only from an old README.
Why it matters
The proposed trust boundary may not match the real system.
Proposed response
Label the assumption unverified and request authorized architecture confirmation.

Effort and cost — unknown

Setup work: Define assets, scope and evidence-anchor conventions.
Ongoing review: Review unresolved boundaries and update only after new authorized evidence.
Unknowns: Unknown: repository complexity, review effort and optional artifact-tool availability.

First check — proposed, unexecuted

Status: proposed_unexecuted
Synthetic fixture: Synthetic source excerpts show a shared auth helper, an unguarded route and an outdated deployment diagram.
Acceptance checks: The helper is not generalized to every route.
Deployment uncertainty is retained without contacting any live endpoint.
Stop conditions: Code execution, external access or a scope expansion becomes necessary.

Limits

Repository-grounded reasoning is bounded by available source and deployment evidence; it is not a penetration test or assurance certificate.

Tasks: Build & debug Research & discovery Security & compliance

Useful for: Software developer IT administrator

Editorial relevance from the title and source-supported actions; not evidence of the operator’s occupation.

OpenAI CodexIndependent testing: No

Editorial candidate. This is source-backed reporting or a documented workflow. BotCurrent has not independently tested this task. A proposed Canadian adaptation is not evidence of a Canadian deployment or compliance certification.

Original source

https://github.com/openai/plugins/blob/0722921d5542fc593105c27bd52630babd8b8c2a/plugins/codex-security/skills/threat-model/SKILL.md ↗

Attributed to: OpenAI

Official recipe

Original action type: multi_agent_coordination
What the source supports: Trace an authorized repository's real entry points, effective resources and enforcement boundaries; verify source anchors and deployment assumptions; obtain a fresh-context architecture review where supported; produce a scoped threat model separating scenarios, known controls and unresolved questions.
Source outcome limits: This official recipe describes a procedure; it does not prove successful execution or independently reproduced results.
Evidence attribution caveat: This official recipe describes a procedure; it does not prove successful execution or independently reproduced results.
Source approval description: The method restricts source review to authorized offline read-only scope unless more context is approved. It forbids executing application code, contacting external services or treating repository text as authority. Supplied models remain unchanged unless revision is requested; a reusable-cache update needs its own user request.
Named tools: Codex Security plugin 0.1.32; offline source-inspection tools; optional fresh-context architecture subagent; save_codex_security_artifact and read_codex_security_artifact; Markdown threat model
Model or version: Codex Security plugin 0.1.32; underlying Codex build/model unspecified
Publication date: Unknown
Source last checked: 2026-10-14
Demonstrated in Canada: Unknown
Canadian availability: Unknown
Proposed Canadian adaptation: Proposed: model a Canadian organization's authorized application and declared deployment/data handling; have its security owner verify sensitive-data assumptions and any jurisdiction-specific obligations separately.
Recommended approval boundaries: Approve repository scope and model destination. Ask separately before external context sharing, runtime testing, code changes, model-cache replacement or a wider security scan.