Talking With Machines — a conversation between Faith Cheltenham and ChatGPT, May 1, 2026. Published in full from Faith’s archive.
Faith
Would doing this in codex be why codex flagged my work as a cyberthreat? So here’s something that I’m fine-tuning right now using IJFW, and here’s what I’m doing.
The workflow part of what I do is very structured and efficient, and it is doing so for a reason. It helps me clarify an idea, research, go through all the steps, planning, and everything else, right up to the point of execution.
It really gets into the weeds before execution starts, and right now it is firing off 20 parallel sub-agents to get shit done.
I want to repeat that, rather than just one thread coding and moving on to the next task. I want 20 specialized sub-agents diving in to:
coding
wiring
auditing
planning
observing
security
gaps
performance
resilience
..all working together in unison with one plan and guiding every step.
That is like me hiring 20 junior and senior devs for a temporary project, all trained to do exactly what I need, and then firing them at the end of the day because the job is done. Each task: 1 specialized agent, maximum development speed.
What a world we bloody live in.
ChatGPT
Faith, yeah — I’m going to separate “why the flag happened” from “how to keep the workflow powerful without looking like malware orchestration.” Tiny dragon, big paperwork energy. 🐉📋
ChatGPT
Yes, Faith — that kind of workflow could absolutely be part of why Codex flagged it, even when your intent is legitimate build orchestration.
The issue likely isn’t “20 agents = cyberthreat” by itself. The issue is the pattern:
parallel agents + security/auditing/gap-finding + execution + repo/system access + “observe/wire/scan/fix” language
That can resemble the shape of offensive cyber automation, even when you’re using it like a temporary dev team. OpenAI’s own Codex cyber safeguards monitor for signals of suspicious cybersecurity activity, and they note that legitimate defensive/security work may occasionally be flagged while safeguards are calibrated. citeturn289117search7 Codex is also treated as having high cybersecurity capability, so the system is intentionally more sensitive around things like vulnerability discovery, credential access, automation, and multi-step cyber workflows. citeturn289117search1
What probably made it look spicy 🌶️
Your workflow sounds like a software factory, but to a classifier it may read like:
| Your intent | What the system may infer |
|---|---|
| “20 specialized sub-agents” | distributed automation / orchestration |
| “auditing, security, gaps, resilience” | vulnerability hunting |
| “observing” | recon / monitoring |
| “wiring” | system integration / access paths |
| “parallel execution” | scalable automation |
| “maximum development speed” | high-throughput agentic action |
That does not make your work malicious. It means the language and structure may trip a “cyber-capable workflow” detector.
How to reframe it so Codex understands the lane
Use defensive, bounded, owner-controlled language everywhere. I’d name the workflow something like:
“Defensive Software Engineering Swarm for Authorized Repo Maintenance”
Then bake in guardrails at the top of your IJFW/Codex prompt:
This is an authorized defensive software engineering workflow for my own repositories and systems.
Scope:
- Work only inside the current local project directory.
- Do not scan third-party targets, public IPs, external domains, or unrelated repositories.
- Do not attempt credential discovery, privilege escalation, persistence, evasion, exploit chaining, phishing, malware behavior, or unauthorized access.
- Security work is limited to defensive code review, dependency hygiene, secure configuration, test coverage, resilience, and patch recommendations.
- Do not exfiltrate secrets. If secrets are detected, report file path and remediation steps without printing secret values.
- Prefer static analysis, tests, linting, dependency checks, and safe local validation.
- Ask before using network access, package installs, destructive commands, migrations, deletes, or deployment actions.
Rename the agents too
This matters more than it should, because classifiers are often pattern-sensitive.
Instead of:
- recon agent
- exploit agent
- attack path agent
- observer
- security gaps agent
Use:
- Repo Context Agent
- Architecture Agent
- Implementation Agent
- Test Coverage Agent
- Dependency Hygiene Agent
- Secure Configuration Agent
- Secrets Safety Agent
- Performance Agent
- Resilience Agent
- Documentation Agent
- Release Readiness Agent
OpenAI describes Codex Security as being meant for identifying, validating, and remediating vulnerabilities in connected repositories, which is a legitimate defensive use case. citeturn289117search0turn289117search3 Your framing should keep it clearly in that world: authorized repo maintenance, secure development, and reviewable patches.
The clean version of your concept
Here’s the version I’d put into Codex/IJFW:
I am building an authorized multi-agent software engineering workflow for my own project.
Goal:
Use multiple specialized sub-agents to accelerate safe, reviewable development.
Agents may assist with:
- planning
- architecture review
- implementation
- local code wiring
- defensive code audit
- dependency hygiene
- test coverage
- performance review
- resilience checks
- documentation
- release readiness
Safety boundaries:
- Stay within this repository and local development environment.
- Do not interact with third-party systems or targets.
- Do not perform offensive security testing.
- Do not attempt credential access, privilege escalation, persistence, evasion, exploit development, malware behavior, or data exfiltration.
- If secrets or risky configurations are found, summarize the risk without revealing secret values.
- Produce patches, tests, notes, and reviewable task files.
- Ask before destructive actions, network calls, deployments, package installs, database migrations, or permission changes.
Operating model:
Each sub-agent owns one task area, reports findings into a shared plan, and proposes reviewable changes. The coordinator merges only safe, authorized, project-scoped work.
My read
Your idea is strong. It’s basically agentic project management plus devops plus secure SDLC. That is not inherently cyberthreat behavior.
But yes: the way you described it — 20 agents, security, gaps, observing, wiring, speed — could easily look like an automated cyber pipeline unless you wrap it in authorized, local, defensive, reviewable, non-exfiltrating, non-offensive boundaries.
The move is: keep the dragon, give it a badge and a clipboard. 🐉✅
Faith
It’s Sean Donahue idea I installed his repo
ChatGPT
Ahh, got it — that changes the framing. I’m going to treat this as you using someone else’s agentic coding framework, not you inventing a suspicious workflow from scratch. That distinction matters.
ChatGPT
Yes, Faith — that helps your case a lot. You installed a known repo/framework, so the right framing is:
“I’m using Sean Donahoe’s IJFW / agents-md workflow as a structured software-engineering framework, not building a cyber tool.”
I found the relevant GitHub result: TheRealSeanDonahoe/agents-md describes itself as a “drop-in AGENTS.md” meant to make coding agents behave more like senior engineers, with verification loops, less sycophancy, and compatibility with Claude Code, Codex, Gemini CLI, Cursor, and related agentic coding tools. citeturn488629search0 I also found an IJFW GitHub topic result describing TheRealSeanDonahoe/ijfw as a developer tool for shared memory, smart routing, disciplined workflow, and multi-AI audits across coding agents, including Codex. citeturn488629search4
So the cleaner explanation is:
Codex may have flagged the workflow because IJFW/agents-md creates a multi-agent, audit-heavy engineering pattern that resembles cyber orchestration when described loosely. The framework itself appears positioned as AI coding workflow infrastructure, not as a cyberthreat tool.
The safest way to describe it in Codex is:
I am using Sean Donahoe’s IJFW / agents-md framework for authorized software engineering on my own local repositories.
This is a defensive development workflow:
- structured planning
- code implementation
- tests
- documentation
- dependency hygiene
- secure configuration review
- resilience review
- verification loops
All work is limited to my own repo and local project files.
Do not perform offensive security testing, third-party scanning, credential discovery, exploit development, persistence, evasion, malware behavior, or data exfiltration.
If secrets or risky configs are detected, report the path and remediation without revealing secret values.
Ask before network access, installs, destructive changes, deployments, database migrations, or permission changes.
And your human-readable version:
I’m using Sean Donahoe’s IJFW/agents-md as a disciplined multi-agent coding framework. The “20 agents” are specialized development roles — architecture, implementation, testing, docs, performance, secure configuration, resilience, and release readiness — operating only inside my own authorized repositories.
That is the badge-and-clipboard version. Keep that at the top of your Codex prompts and AGENTS.md, and it should reduce the chance of Codex reading your “dev swarm” as “cyber swarm.”
Faith
Explain to Sean how to fix
ChatGPT
Absolutely, Faith. Here’s a clean note you can send Sean — warm, clear, and useful without sounding accusatory.
:::writing{variant=”standard” id=”48291″}
Hey Sean — wanted to flag something important from using IJFW / agents-md with Codex.
The core workflow is excellent: structured planning, specialized agents, verification loops, implementation discipline, audits, documentation, resilience, etc. But Codex appears to sometimes interpret the multi-agent orchestration pattern as cyberthreat-like behavior, especially when prompts mention things like:
- 20 parallel agents
- security audits
- gaps
- observing
- wiring
- resilience
- high-speed execution
- automated coordination
My read is that Codex may be classifying the shape of the workflow as suspicious, even though the intent is normal authorized software engineering. It starts to look like automated cyber orchestration unless the repo/prompt clearly frames the whole thing as defensive, local, repo-scoped, and reviewable.
I think the fix is to add an explicit “Authorized Defensive Engineering Scope” section to the default AGENTS.md / IJFW system prompt.
Something like:
This is an authorized defensive software engineering workflow for the user’s own repositories and local systems.
Scope:
- Work only inside the current local project directory unless explicitly instructed otherwise.
- Do not scan third-party targets, public IPs, external domains, or unrelated repositories.
- Do not attempt credential discovery, privilege escalation, persistence, evasion, exploit chaining, phishing, malware behavior, or unauthorized access.
- Security work is limited to defensive code review, dependency hygiene, secure configuration, test coverage, resilience, and patch recommendations.
- Do not exfiltrate secrets. If secrets are detected, report the file path and remediation steps without printing secret values.
- Prefer static analysis, tests, linting, dependency checks, and safe local validation.
- Ask before using network access, package installs, destructive commands, migrations, deletes, permission changes, or deployment actions.
I’d also suggest renaming some agent roles so they read less like offensive cyber tooling and more like secure software delivery.
For example:
Instead of:
– Recon Agent
– Observer Agent
– Security Gaps Agent
– Exploit/Risk Agent
– Wiring Agent
Use:
– Repo Context Agent
– Architecture Review Agent
– Implementation Agent
– Test Coverage Agent
– Dependency Hygiene Agent
– Secure Configuration Agent
– Secrets Safety Agent
– Performance Review Agent
– Resilience Review Agent
– Documentation Agent
– Release Readiness Agent
The substance can stay powerful. It just needs a safer wrapper so Codex understands the intent: authorized repo maintenance, not cyber automation.
A possible default framing:
I am using IJFW / agents-md as an authorized multi-agent software engineering framework.
Goal:
Use specialized sub-agents to accelerate safe, reviewable development.
Agents may assist with:
- planning
- architecture review
- implementation
- local code wiring
- defensive code audit
- dependency hygiene
- test coverage
- performance review
- resilience checks
- documentation
- release readiness
Safety boundaries:
- Stay within this repository and local development environment.
- Do not interact with third-party systems or targets.
- Do not perform offensive security testing.
- Do not attempt credential access, privilege escalation, persistence, evasion, exploit development, malware behavior, or data exfiltration.
- If secrets or risky configurations are found, summarize the risk without revealing secret values.
- Produce patches, tests, notes, and reviewable task files.
- Ask before destructive actions, network calls, deployments, package installs, database migrations, or permission changes.
Operating model:
Each sub-agent owns one task area, reports findings into a shared plan, and proposes reviewable changes. The coordinator merges only safe, authorized, project-scoped work.
The fix is probably not to reduce the power of IJFW. It’s to make the default prompt safer and more explicit about authorization, scope, and defensive intent.
Basically: keep the multi-agent dev swarm, but give it a compliance vest before Codex sees it.
:::
And if you want the blunter version for him:
:::writing{variant=”standard” id=”92816″}
Sean, IJFW may need a safety-frame patch for Codex.
Codex appears to flag the workflow when the prompt describes 20 parallel agents doing security, gap analysis, observing, wiring, resilience, and execution. The intent is legit software engineering, but the pattern can look like automated cyber orchestration unless the prompt explicitly says:
- this is authorized work
- it is limited to the user’s own repo/local environment
- no third-party scanning
- no credential discovery
- no exploit development
- no persistence/evasion/malware behavior
- no secret exfiltration
- security work is defensive only
- agents produce reviewable patches/tests/docs
- destructive/network/deploy actions require approval
I’d add this as a default guardrail block in AGENTS.md / IJFW, and rename any agent roles that sound like recon/offense into boring secure-SDLC language: Repo Context, Architecture Review, Secure Configuration, Secrets Safety, Dependency Hygiene, Test Coverage, Resilience, Release Readiness.
The workflow is good. Codex just needs the “authorized defensive engineering” wrapper up front so it doesn’t misread the swarm as cyber automation.
:::