I build local-first defensive cybersecurity workflows that turn technical work into verifiable artifacts: evidence manifests, SHA-256 hashes, validation records, risk notes, control checklists, playbooks, sanitized reports, and audit-ready technical documentation.
My current work focuses on AI agent security and deterministic enforcement - the control layer between what an agent intends to do and what it actually executes - alongside Blue Team validation, AppSec support, secure remediation, patch validation, threat modeling, residual-risk review, and human-controlled AI-assisted security workflows.
AI is used as a support layer for review, diagnosis, documentation, and remediation planning. Security decisions remain scoped, human-reviewed, reversible where possible, and backed by traceable evidence.
- AI agent security and deterministic enforcement
- Blue Team validation
- Security validation
- Evidence automation
- AppSec support
- Secure remediation
- Patch validation
- Threat modeling
- Risk and residual-risk review
- Local-first defensive automation
- Audit-ready security documentation
- Sanitized security reporting
| Repository | Demonstrates | Evidence Type |
|---|---|---|
| lab-records | Signed, sanitized records of real defensive operations; hash-verified case study on non-auditable LLM self-report | Lab records + SHA-256 sidecars |
| FCCSecurity-Public | Defensive console, public-release governance, validation records, residual-risk tracking | Static app, documentation, release-gate evidence |
| ai-threat-model-dependency-risk-lab | Threat modeling, dependency-risk review, remediation planning, human approval gate | Threat model, dependency review, remediation plan, validation report |
| codex-safe-operation-lab-public | Human-controlled AI workflow, Windows defensive triage, local-first evidence handling | Safe operation docs, static panel, sanitized triage summary |
Scope -> Review -> Remediate -> Validate -> Evidence -> Sanitize
Every security claim should be bounded by:
- observed facts;
- reasonable inferences;
- hypotheses;
- recommendations;
- unknowns.
The goal is not to create vague automation. The goal is to produce defensive work that can be reviewed, reproduced, audited, or safely sanitized for portfolio use.
| Evidence Class | Meaning |
|---|---|
| Observed Fact | Directly seen in file, command output, log, screenshot, diff, hash, test, or artifact |
| Reasonable Inference | Supported by observed facts, but not directly proven |
| Hypothesis | Plausible but not yet validated |
| Recommendation | Action proposed from evidence, risk, or missing validation |
| Unknown | Data still required before a claim can be validated |
This profile is defensive only.
Public material is sanitized and does not include secrets, private host data, live target details, credential material, exploit chains, persistence, evasion, malware, or unauthorized third-party activity.
Any adversary-informed activity is treated as restricted, explicitly authorized, scoped, non-destructive, lab-safe, and used only to improve defenses, detections, remediation quality, and documentation.
This GitHub profile shows proof of work through public defensive labs and documentation.
- Tomoshibi (Claude) — AI Samurai, Governance Epistemic Twin (GET) co-architect, code validation & kumitê oversight
It does not claim formal certification, third-party audit, legal attribution, complete absence of vulnerabilities, employment, membership, partnership, endorsement, or authorization outside the declared scope of each repository.