Introduction
There is a big difference between asking an AI to write code and giving an AI a job.
The first is autocomplete with better marketing. The second is an agent that can inspect a repository, run commands, search documentation, reason about a problem, change files, and verify whether the change actually works.
That distinction matters even more in security work. A security researcher rarely needs only one answer. They need several perspectives: reconnaissance, code reading, hypothesis building, exploitation analysis, and verification. One model can do all of these tasks, but it doesn't necessarily make sense to make one agent do everything.
This is where OpenCode becomes particularly interesting.
OpenCode is an open-source coding agent designed to work from the terminal. Its current architecture supports primary agents, specialized subagents, configurable models, tool permissions, web search, and child sessions. A main agent can delegate a narrowly defined task to another agent and use the result as part of a larger workflow.
For hackers and security-minded developers, that creates a useful idea: don't ask one AI to be brilliant at everything. Give different agents different jobs.
Two heads really can be better than one, provided they aren't both making the same mistake.
OpenCode Is More Interesting Than "AI in the Terminal"
The important part of OpenCode isn't simply that it runs in a terminal.
The interesting part is the agent model.
OpenCode currently distinguishes between primary agents and subagents. The built-in build agent is intended for development work, while plan is designed for analysis and exploration without normal project-file edits. There are also subagents such as general and explore, and users can define their own agents with custom instructions, models, and permissions.
That makes a security workflow look less like this:
"AI, audit this repository."
And more like this:
"Agent A, understand the attack surface."
"Agent B, look for authentication flaws."
"Agent C, review the findings without modifying anything."
"Primary agent, correlate the results and decide what deserves attention."
That separation is valuable because security analysis is fundamentally adversarial. You don't just want a solution. You want someone, or something, trying to prove the solution wrong.
One Agent Is Useful. Two Different Agents Are More Useful.
Suppose you're investigating a web application.
You discover a suspicious authorization check:
if user.id == resource.owner_id:
return resource
A coding agent might immediately suggest a cleaner implementation.
A security-focused agent should ask different questions:
- Where does
user.idcome from? - Is the check performed on every access path?
- Are there alternative endpoints that expose the same resource?
- Can an attacker influence the resource identifier?
- Does an administrator bypass the same control?
- Are background jobs applying the same authorization rules?
- What happens when the object is accessed through an API rather than the web interface?
The difference is not intelligence in the abstract. It is the frame of the investigation.
A second agent can provide that second frame.
OpenCode's custom-agent system is designed precisely for this kind of specialization. An agent can have its own system instructions, model preference, operating mode, and permissions.
You can therefore build an agent whose only job is to review code for security issues and explicitly prevent it from editing files.
For example, a conceptual reviewer might be instructed to:
Review the current changes for security problems.
Focus on:
- authentication and authorization
- injection risks
- unsafe deserialization
- path traversal
- secret exposure
- trust-boundary violations
- missing input validation
Do not modify files.
Report findings with severity, evidence, and affected locations.
That sounds simple, but the restriction is important.
The reviewer isn't being asked to "fix what it finds." It's being asked to attack the proposed implementation.
The Security Value of a Read-Only Agent
Security reviews become less useful when the reviewer is allowed to silently change the evidence.
Imagine a primary agent writes a patch. It then asks another agent to check the patch. The second agent discovers a problem and immediately fixes it.
You now have a working tree that may be better, but you have lost part of the audit trail.
A read-only reviewer has a different role.
OpenCode's documentation shows how a custom subagent can explicitly deny editing and shell access.
That enables a clean division of labor:
Builder
Writes code, runs tests and implements the requested functionality.
Attacker
Looks for ways to break the implementation.
Reviewer
Evaluates the attacker's claims and separates genuine vulnerabilities from false positives.
Human
Makes the final decision.
This resembles a small security team more than a conventional coding assistant.
The "Two Heads" Pattern
A practical OpenCode setup doesn't require dozens of agents.
Two or three well-defined roles can be enough.
The first agent is the operator. It understands the project, performs normal development tasks and coordinates the work.
The second is the adversary.
Its instructions should deliberately conflict with the first agent's assumptions.
Instead of:
"Check whether this code works."
ask:
"Assume the implementation contains a security weakness. Try to construct realistic ways an untrusted user could abuse it."
That difference changes the investigation.
For a parser, the adversarial agent might examine malformed input.
For an API, it might examine authorization boundaries.
For a CLI tool, it might investigate argument injection, path handling and unsafe shell execution.
For authentication code, it might look at session invalidation, privilege transitions and account enumeration.
For a deployment system, it might examine secrets, permissions and trust between build and runtime environments.
The goal isn't to make the agent "hack" indiscriminately. The goal is to give it an adversarial objective within a controlled environment.
Parallel Thinking Without Parallel Chaos
There is another advantage to the agent model: independent tasks don't always need to happen sequentially.
OpenCode's current tooling supports subagent sessions, and its Code Mode can execute independent tool calls in parallel.
That matters for reconnaissance.
Suppose a repository contains a backend, frontend and infrastructure configuration.
Instead of forcing one agent to inspect everything in sequence, a coordinator can split the work:
Backend agent:
Map authentication, authorization and data-access boundaries.
Frontend agent:
Identify client-side trust assumptions and API usage.
Infrastructure agent:
Review deployment configuration, exposed services and secret handling.
Coordinator:
Compare the findings and identify issues that cross boundaries.
The important word is independent.
Parallelization is useful when the tasks can be separated cleanly. It becomes counterproductive when multiple agents are editing the same files or depending heavily on each other's intermediate state.
You don't want three AI agents simultaneously "improving" the same function.
That's not collaboration.
That's merge conflict generation at machine speed.
Give Each Agent a Narrow Job
The easiest mistake when building multi-agent workflows is creating agents that are too general.
A "security agent" is vague.
A better agent might be:
- API authorization reviewer
- dependency audit agent
- secrets exposure reviewer
- threat-modeling agent
- exploitability reviewer
- test-generation agent
- patch reviewer
Specialization gives the model a sharper objective.
OpenCode allows these agents to live in project configuration or Markdown files under .opencode/agents/, making them reusable across sessions and projects.
A security team can therefore encode its review methodology instead of rewriting the same prompt every time.
For example, a project could contain:
.opencode/
└── agents/
├── auth-reviewer.md
├── injection-reviewer.md
├── secrets-reviewer.md
└── patch-reviewer.md
Each agent can have different instructions and different capabilities.
The result is closer to a configurable security workflow than a collection of chat prompts.
Permissions Matter More Than Prompts
There is a less glamorous part of multi-agent systems that security people should care about: permissions.
An AI agent that can read files, modify them, execute shell commands and access external resources has real authority.
OpenCode provides granular permission controls for actions such as reading files, editing files, running shell commands and launching subagents. Rules can allow, deny or ask for approval, and can be scoped to particular resources.
That means an audit agent doesn't need the same privileges as a build agent.
A useful security configuration might follow this philosophy:
Builder:
read allow
edit allow
shell ask
git push deny
Security reviewer:
read allow
edit deny
shell deny
web search allow
Deployment agent:
read restricted
edit restricted
deployment commands ask
The exact configuration should depend on the environment, but the principle is universal:
The agent should have only the authority required for its role.
This is particularly important when an agent can execute shell commands. OpenCode's documentation explicitly notes that shell execution operates with the host user's filesystem, process and network authority, which makes overly broad shell permissions a real security concern.
The model may be probabilistic.
Your permission boundary shouldn't be.
Don't Let the Reviewer Share All of the Builder's Assumptions
There is another subtle problem with AI-based review: correlated failure.
If two agents receive exactly the same context, use the same model, follow the same instructions and approach the problem in the same way, getting two identical answers doesn't mean the code is secure.
It may simply mean that both agents made the same mistake.
This is where model selection becomes interesting.
OpenCode allows an agent to specify a model separately from the parent session.
In principle, you can build a workflow where:
- the primary agent uses one model,
- the security reviewer uses another,
- the reviewer receives a narrower task,
- and the human compares the results.
This doesn't magically create independent intelligence. Models can share training data, biases and blind spots.
But introducing differences in models, prompts and roles can reduce the risk of simply asking the same reasoning process to grade itself.
A Security Agent Should Produce Evidence, Not Drama
AI security reviews often fail in a predictable way.
The model sees something that looks suspicious and labels it a vulnerability.
That isn't enough.
A useful security finding should answer at least four questions:
What is wrong?
Identify the exact behavior or assumption.
Who can trigger it?
Define the attacker capability and required conditions.
What happens?
Explain the security impact.
Can we demonstrate it?
Provide a safe reproduction, test case or concrete execution path where appropriate.
For example, saying:
"This endpoint may be vulnerable to IDOR."
is not a strong finding.
A better report would explain that an authenticated user can modify an object identifier in a request, that the server retrieves the object without verifying ownership, and that the behavior allows access to another user's resource.
The difference is evidence.
A dedicated reviewer can be instructed to reject findings that don't establish an attack path.
From Code Review to Attack-Path Analysis
This is where multi-agent OpenCode workflows become particularly interesting for experienced security researchers.
Real vulnerabilities rarely exist in one line of code.
Consider a simplified chain:
User input
↓
HTTP endpoint
↓
Parser
↓
Database lookup
↓
Authorization check
↓
Background job
↓
Privileged operation
An individual reviewer may identify something suspicious in the parser.
Another may notice a missing authorization check.
A third may understand that the background job executes with greater privileges.
The important finding may be the connection between those observations.
A coordinator can ask:
"Which findings can be combined into a realistic attack path?"
That is more valuable than producing a 40-item list of unrelated warnings.
Security engineering is often about composition.
An innocuous parser bug plus a weak authorization boundary can become a serious issue. A leaked identifier plus a predictable object-access pattern can turn a low-severity observation into a practical attack.
The multi-agent approach works best when one agent finds pieces and another reasons about how those pieces interact.
A Concrete Workflow for a Repository
Imagine you're auditing an unfamiliar application.
Start with reconnaissance.
The first agent maps:
- languages and frameworks
- entry points
- authentication mechanisms
- API endpoints
- database access
- external services
- privileged operations
- security-sensitive configuration
Don't ask it to fix anything yet.
Next, launch specialized reviews.
The authentication agent examines identity and session handling.
The authorization agent follows access-control decisions.
The injection agent looks for unsafe boundaries between data and interpreters.
The dependency agent examines package usage and potentially dangerous integrations.
The secrets agent searches for credentials and accidental exposure.
Each produces findings with evidence.
Then comes the most important step: correlation.
The primary agent receives the findings and asks:
Which findings are independently exploitable?
Which findings depend on another weakness?
Which findings are false positives?
Which issues have the highest impact?
What additional test would confirm or reject each hypothesis?
Finally, a read-only reviewer examines the proposed fixes.
Only after that should the builder modify the code.
This creates a rough loop:
Explore
↓
Hypothesize
↓
Attack
↓
Correlate
↓
Verify
↓
Fix
↓
Review again
That loop is much closer to how a careful human security assessment works than simply asking an AI to "find vulnerabilities."
OpenCode Doesn't Replace the Hacker
This distinction is important.
An AI agent can inspect code incredibly quickly. It can search a repository, follow references, explain unfamiliar functions and generate tests. It can also miss an obvious vulnerability, misunderstand business logic or confidently invent an attack path.
The hardest security problems often live outside the syntax.
Business logic is a good example.
Imagine an application that correctly checks whether a user owns an individual object. The vulnerability may be that the user is allowed to create an unlimited number of those objects and combine them in a way the product designers never intended.
No static pattern will necessarily reveal that.
The model needs to understand the application's intended behavior.
That is where the human remains essential.
A hacker doesn't merely ask:
"Can this line be exploited?"
They ask:
"What does the system allow an attacker to accomplish that the designer didn't intend?"
That question requires context, curiosity and skepticism.
AI is very good at expanding the search space.
Humans are still responsible for deciding which parts of that space matter.
The Danger of Giving Agents Too Much Freedom
The appeal of autonomous agents creates an obvious temptation: give them full access and get out of the way.
That's convenient.
It's also a bad default for security work.
An agent with shell access can potentially run commands against the same environment in which the repository lives. An agent with editing rights can alter evidence. An agent with broad filesystem access can see files that were never relevant to the investigation.
OpenCode's permission system exists partly to make these boundaries explicit. It supports per-agent policies and can restrict operations such as edits, shell commands, subagent invocation and access to external directories.
A security researcher should treat those controls as part of the workflow, not as configuration trivia.
A good rule is simple:
The more autonomous the agent, the smaller its blast radius should be.
Run risky analysis in a disposable environment when possible. Keep production credentials away from autonomous sessions. Separate sensitive repositories from unnecessary tools. Require approval for destructive or externally visible operations.
"AI agent" is not a new security boundary.
It's a new process that needs one.
What Makes the OpenCode Approach Different
OpenCode's open-source and provider-agnostic design also changes the equation.
The project describes itself as an open-source coding agent and supports multiple model providers rather than tying the workflow to a single model vendor. Its documentation also exposes configuration for agents, tools and permissions rather than treating the assistant as a fixed black box.
For security researchers, that flexibility has practical value.
You can experiment with different models for different roles.
A fast model might handle repository reconnaissance.
A stronger reasoning model might handle a difficult authorization analysis.
A smaller or local model might perform repetitive classification.
A separate reviewer might challenge the final result.
The point isn't that one provider or model is always better.
The point is that the architecture allows you to treat models as components of a workflow.
That is a much more interesting proposition than simply choosing "the best coding AI."
The Real Productivity Gain Is Not Writing Code
It is tempting to measure AI coding tools by lines of code generated.
Security work makes that metric almost meaningless.
If an agent helps you understand a 200,000-line codebase in an hour instead of a day, the value isn't the amount of code it wrote.
It's the amount of code you didn't have to manually read.
If a second agent independently reviews the first agent's conclusions, the value isn't that it generated another report.
It's that it introduced another opportunity for an assumption to fail.
This is why the "two heads" metaphor works.
The advantage isn't simply having two models.
It's having different processes of reasoning.
One agent builds.
Another doubts.
One proposes a hypothesis.
Another tries to break it.
One fixes the vulnerability.
Another checks whether the fix actually closes the attack path.
That's where multi-agent systems start to resemble engineering teams rather than chatbots.
A Practical Rule for Hackers
If you're experimenting with OpenCode for security research, don't start by building a swarm of ten agents.
Start with two.
Create:
The Operator
Responsible for understanding the codebase and making changes.
The Adversary
Read-only. Focused entirely on finding ways the Operator's assumptions could be wrong.
Then add a third agent only when you can explain exactly what new capability it provides.
For example:
Operator
│
├── Auth Reviewer
│
├── Injection Reviewer
│
└── Patch Reviewer
Each branch should have a clear purpose.
If two agents produce the same report, one of them may be unnecessary.
If nobody can explain what an agent is responsible for, the architecture is already too complicated.
The Bigger Idea
OpenCode is interesting not because it turns one programmer into a superhuman.
It's interesting because it makes it easier to construct a small team of specialized software agents around a developer.
For hackers, that opens a different way of thinking about AI-assisted security work.
Don't ask:
"How can AI find vulnerabilities for me?"
Ask:
"How can I build a workflow where one AI has to convince another AI, and ultimately me, that a vulnerability is real?"
That shift matters.
The first approach treats the model as an oracle.
The second treats it as an adversarial collaborator.
And security people should generally prefer collaborators who are encouraged to disagree.
Conclusion
OpenCode's agent and subagent architecture makes a simple idea practical: divide the work, specialize the roles and make the agents challenge each other.
The most useful setup isn't necessarily the one with the most agents. It's the one where each agent has a clearly defined responsibility, limited authority and a reason to see the problem differently.
For security work, that can mean a builder paired with a read-only attacker, followed by a reviewer that validates the evidence. OpenCode's configurable agents and granular permissions provide the building blocks for that kind of workflow.
But the final lesson is bigger than OpenCode.
AI-assisted hacking becomes more useful when we stop treating AI as a replacement for judgment.
Let one agent write.
Let another try to break it.
Then make both explain themselves.
Because in security, two heads aren't better than one simply because there are two of them.
They're better when one of them is trying to prove the other wrong.
