skill
trust-boundary-security-engineer
A portable, documentation-first AI skill for security engineering reasoning — adversarial thinking, evidence over assumptions, temporal trust boundaries, and structured findings.
Set up
Skills are installed by placing their folder where your agent loads skills.
The download comes from github.com/Ponce1969/trust-boundary-security-engineer itself, not from our server, so what you get is exactly what its author published.
Install instructions come from the README
README
synced Oct 22, 2026Trust Boundary
Stable / Technology-Agnostic Security Reasoning Core for AI Agents
A portable, documentation-first reasoning framework that teaches agents to think like responsible senior security engineers — adversarially, methodically, and with evidence over assumptions.
No code · No packages · No installation · Just knowledge, principles, and structured reasoning
Why This Exists
Most security tools find problems. This skill teaches how to think about them.
It gives AI agents a structured reasoning framework — perceive input, construct context, generate hypotheses, evaluate evidence, synthesize decisions — instead of a list of rules to check off.
The result: findings that are proportional, evidence-backed, and teach the reader why something matters, not just that it does.
Who This Is For
| Who | Why |
|---|---|
| AI agent developers | Want agents that reason about security instead of pattern-matching vulnerability names |
| Security engineers | Review code with AI assistance and want structured, proportional findings |
| Platform teams | Build concurrent or distributed systems and need temporal reasoning, not just spatial analysis |
What Makes This Different
| Typical Security Tool | Trust Boundary Skill |
|---|---|
| Pattern-matches vulnerability names | Reasons from evidence through structured hypotheses |
| Treats all findings equally | Qualifies findings as structurally guaranteed or time-dependent |
| Reports controls as binary present/absent | Evaluates control sufficiency — present but inadequate is a different finding |
| Analyzes code at a single point in time | Models state evolution across execution time |
| Ignores concurrency or treats it as a special case | Constructs temporal trust boundaries alongside spatial ones |
| Outputs flat vulnerability lists | Structures findings as Observations · Inferences · Risks with explicit confidence levels |
| Stops at "control missing" | Asks "is the control sufficient for this threat model?" |
How It Works
The skill applies a six-step reasoning model when a security lens changes the analysis:
Key Reasoning Capabilities
Execution Model Classification Before reasoning, the agent classifies the system's execution model (sequential, concurrent, distributed, or mixed). This determines which hypothesis categories are mandatory rather than optional.
State Evolution Modeling For concurrent and distributed systems, shared mutable state is traced from creation through mutation to disposal. Windows where state is inconsistent, partially committed, or visible to unauthorized actors are identified across execution time — not just at a single snapshot.
Temporal Trust Boundaries Traditional analysis identifies spatial boundaries (service-to-service, layer-to-layer). This skill also identifies temporal boundaries — where concurrent execution allows state from one context to leak into another without explicit synchronization.
Defensive Control Sufficiency A control that exists but is inadequate for the threat model is a different finding than a control that is absent. A rate limiter with ±10% jitter under 100 concurrent requests is present but insufficient. The skill evaluates sufficiency, not just presence.
Temporal Qualification of Conclusions Findings are classified as structurally guaranteed (hold regardless of execution order) or time-dependent (manifest under specific interleavings). This prevents treating race conditions as deterministic or dismissing them as unlikely.
Security Controls Undermined by Retries A security mechanism that works in normal conditions may fail under retry or concurrent execution. Rate limits consumed by retry storms, account lockout counters bypassed by parallel attempts — these are hypotheses where the control exists but is undermined by the execution model.
Distributed Inconsistency Resolution When a system can reach inconsistent state, the resolution mechanism determines the security impact. Last-writer-wins silently discards authorized changes. Manual reconciliation leaves inconsistency indefinitely. Automatic merge may produce unintended state. The skill evaluates the resolution, not just the inconsistency.
Repository Structure
security-engineer-skill/
├── README.md ← You are here
├── LICENSE ← MIT
├── AGENTS.md ← Agent behavior rules and contribution guidelines
├── SKILL.md ← Skill definition, activation, and context loading
│
├── specs/ ← What the project is and how it behaves
│ ├── SPEC-001 ← Project vision and scope
│ ├── SPEC-002 ← Architecture and directory responsibilities
│ ├── SPEC-003 ← Behavioral principles and communication norms
│ ├── SPEC-004 ← Content organization rules
│ ├── SPEC-005 ← Agent reasoning model (the core)
│ └── SPEC-006 ← Skill extension protocol & precedence rules
│
├── principles/ ← How the skill thinks (foundational axioms)
├── knowledge/ ← What the skill knows (technology-agnostic concepts)
├── checklists/ ← What the skill checks (general software verification)
├── patterns/ ← Concrete security patterns (emerging, validated, established)
├── examples/ ← How the skill applies (worked walkthroughs)
├── references/ ← Where the skill points (external standards)
└── docs/ ← Architecture proposals and refactor history
└── architecture/
What's Inside
| Spec | Purpose |
|---|---|
| SPEC-001 | Project vision and scope |
| SPEC-002 | Repository structure and directory responsibilities |
| SPEC-003 | Behavioral principles and communication norms |
| SPEC-004 | How content should be written and organized |
| SPEC-005 | How the agent processes, reasons, and decides |
| SPEC-006 | Extension protocol, precedence rules, and domain contracts |
| Principle | Core Idea |
|---|---|
| Evidence over Assumptions | Base findings on observable evidence. Say so when evidence is unavailable. |
| Education over Fear | Teach and explain. Do not overwhelm with warnings. |
| Human in the Loop | Inform and support decisions. Never replace human judgment. |
| Minimal Change | Prefer the smallest safe change that solves the problem. |
| Context Matters | Interpret every finding within its environment and intended use. |
| Control Sufficiency | A control that exists but is inadequate for the threat is a different finding than a control that is absent. |
| Concept | Key Insight |
|---|---|
| Secure by Default | The path of least resistance should be the safe path. |
| Least Privilege | Give only the permissions needed — nothing more. |
| Defense in Depth | No single control should be the only one standing. |
| Input Validation | Define what is acceptable. Reject everything else. |
| Secrets Management | A leaked secret is an identity compromise, not a data breach. |
| Secure Serialization | Reconstruction is an active operation, not a passive one. |
| Trust Boundaries | Every point where data changes trust level is a security boundary. |
| Supply Chain Security | Every dependency is a trust decision — most are made implicitly. |
| Threat Modeling | Identify risks before they become incidents, not after. |
| Error Handling and Secure Failure | When something goes wrong, the system should become more restrictive, not less. |
| Checklist | Purpose |
|---|---|
| Repository Entry Scan | Entry protocol for any unfamiliar repository — classify, scan for signals, select the right checklist |
| Security Code Review | Review code changes for security concerns |
| Secrets Management Review | Review how a system handles credentials and secrets |
| Threat Modeling Review | Conduct a structured threat model |
| ID | Pattern | Execution Model | Confidence |
|---|---|---|---|
| PAT-001 | Mutable Singleton | Concurrent | established |
| PAT-002 | Request Lifetime Mismatch | Concurrent | established |
| PAT-003 | Background Task Lifetime Leak | Concurrent | validated |
| PAT-004 | Cryptographic Secret Reuse | Sequential, Concurrent, Distributed, Mixed | established |
| PAT-005 | Control Present but Insufficient | Concurrent | validated |
| Reference | What it covers |
|---|---|
| OWASP and Vulnerability Standards | OWASP Top 10, CWE Top 25, ASVS, Cheat Sheet Series — with direct mappings to this skill's knowledge files |
| Threat Modeling Frameworks | STRIDE, PASTA, LINDDUN, Attack Trees, MITRE ATT&CK, NIST SP 800-30 — when and how to apply each |
| Cloud and Infrastructure Security | AWS Well-Architected, CIS Benchmarks, CSA CCM, NIST SP 800-190 for containers, MITRE ATT&CK for Cloud |
| Example | Demonstrates |
|---|---|
| Authentication Bypass Review | Full reasoning loop: perception, context, hypothesis, evidence, output |
| Concurrent Payment Review | Temporal trust boundaries, state evolution modeling, execution model classification, defensive control sufficiency, temporal qualification, [REQUIRES_EXTERNAL_EVIDENCE] |
| TalkTalk Breach Case Study | Real-world incident analysis: structurally guaranteed findings, confirmed by absence of control, defense in depth, legacy system risks |
| IAC and Cloud Misconfiguration Review | Cloud-native attack surfaces: IAM wildcard policies, public S3 buckets, hardcoded credentials in CI/CD, blast radius amplification |
| Web App Container Audit | TOCTOU in password reset, Docker network trust boundaries, XSS in server-rendered HTML, control sufficiency in rate limiting |
Core Architecture & Specialized Extensions
Trust Boundary operates as the Stable / Technology-Agnostic Security Reasoning Core. Following SPEC-006 (Skill Extension Protocol), specialized domain auditor skills build on top of its reasoning engine without duplicating or weakening its foundational axioms:
Trust Boundary Core (security-engineer-skill)
[Stable / Technology-Agnostic Reasoning Core]
│
▼
Extension Protocol (SPEC-006)
[Precedence, Compatibility & Contracts]
│
▼
Specialized Auditors (e.g., agentic-security-auditor)
[Domain-Specific Specializations & Evidence Collectors]
- Precedence Rule: An extension may specialize and expand the Core, but cannot contradict its axioms, evidence model, execution model, trust-boundary model, or control-sufficiency model.
- Core Independence: Trust Boundary Core has zero operational dependency on extensions. It functions autonomously for general software engineering audits.
- Available Extensions:
- Agentic Security Auditor: Specialization for AI agents, multi-agent frameworks, MCP (Model Context Protocol), tool calling security, RAG/memory poisoning, the 3-Layer Sufficiency Rubric (Prompt/Arch/API), MAESTRO 7-layer taxonomy, and passive evidence collectors (
audit_docker.py,audit_network.py,audit_secrets.py).
- Agentic Security Auditor: Specialization for AI agents, multi-agent frameworks, MCP (Model Context Protocol), tool calling security, RAG/memory poisoning, the 3-Layer Sufficiency Rubric (Prompt/Arch/API), MAESTRO 7-layer taxonomy, and passive evidence collectors (
Platform Compatibility
This skill works with any AI agent that reads AGENTS.md or SKILL.md. Each platform uses a different mechanism — the table below shows the correct integration point for each:
| Platform | Integration file | How to activate |
|---|---|---|
| Kiro | SKILL.md | Place in .kiro/skills/security-engineer/ in the workspace |
| OpenCode | SKILL.md | Place in ~/.config/opencode/skills/security-engineer/ |
| Claude Code | CLAUDE.md | Copy or reference AGENTS.md content into CLAUDE.md at the project root |
| Cursor | .cursorrules | Copy or reference AGENTS.md content into .cursorrules |
| Gemini CLI | GEMINI.md | Copy or reference AGENTS.md content into GEMINI.md |
| Any agent | SKILL.md or AGENTS.md | Point the agent to SKILL.md as the activation contract. If the platform reads a different file, copy the activation rules into that file. |
Note on portability: The skill content (knowledge, principles, checklists, examples) is platform-agnostic Markdown. Only the activation contract (the file that tells the agent when and what to load) needs to be adapted per platform.
Quick Start
- Read
SKILL.md— the activation contract and context loading rules - Start with
SPEC-005— the core reasoning model - Try the
Concurrent Payment Review— see the skill in action - Activate by placing
SKILL.mdin your agent's skills directory
License
MIT — Use it, modify it, share it.