Gibson ADK's Zero Trust Runtime: How Bug Bounty Automation Agents Enforce Security Boundaries at the Tool Layer

Offensive security agents need to run reconnaissance, enumerate attack surfaces, and sometimes exploit vulnerabilities. The problem: an agent that can scan a network can also pivot into production systems, leak credentials, or execute destructive payloads. Traditional sandboxing breaks the workflow. No sandbox lets the agent escalate when it finds a valid exploit path.

Gibson ADK and its Zero Trust Runtime solve this by enforcing security boundaries at the tool layer. Every tool call runs in its own microVM with declared egress. The runtime holds grants (delegated permissions from a named person), checks missions (typed work graphs) at submit time, and logs every action to a replayable timeline. An agent can discover a critical vulnerability, but the runtime decides whether exploitation is allowed.

This is not theoretical. The builder spent 15 years in DevSecOps and offensive security, then built an agent framework for bug bounty automation. The constraints are real: agents must run recon at scale, but they cannot accidentally pivot from reconnaissance to destructive actions.

The Six-Control Model

Gibson enforces six controls. Each one is either enforced (runtime blocks the action), conditional (requires human approval), or structural (the architecture prevents it by design).

Control	Type	Enforcement Point	What It Stops
Identity	Structural	Runtime holds agent identity and grant	Agent cannot impersonate another user or escalate its own permissions
Mission scope	Enforced	Typed work graph checked at submit	Agent cannot deviate from declared objectives or add unauthorized tasks
Execution environment	Structural	Each tool run in isolated microVM	Tool cannot access runtime memory, other agents, or host filesystem
Egress policy	Enforced	Component declares allowed network destinations	Tool cannot exfiltrate data to undeclared endpoints
Knowledge graph	Conditional	Findings stored per tenant, access logged	Agent cannot read another tenant's discovered vulnerabilities
Replay audit	Structural	Every run rebuilt move by move	No action is unattributable; every decision has a trace

The runtime does not trust the agent. It trusts the grant (what a human delegated) and the mission (what the human approved). The agent is untrusted code that runs in a sandbox.

Architecture: Runtime, Console, and Execution Environment

Gibson splits into three layers:

Gibson Runtime is the server. It holds agent identities, stores grants, runs missions, decides where work executes, and writes every event to the timeline. The runtime is the source of truth for what an agent is allowed to do.

Gibson Console is the web UI. You create missions, set grants and budgets, browse the knowledge graph (hosts, paths, findings per tenant), read traces, and replay any run. The console does not execute agent code. It only reads from the runtime and submits missions.

Execution environment is where untrusted work runs. Setec (the execution layer) puts each tool run in its own microVM, on its own kernel, with the egress the component declared. The runtime dispatches into it and reads the result back. The tool cannot see the runtime, other tools, or the host.

This separation matters. If an agent discovers a remote code execution vulnerability, the tool that would exploit it runs in a microVM with no access to the runtime's credential store. The agent can propose exploitation, but the runtime checks the mission scope and grant before dispatching the tool.

How Missions Constrain Agent Behavior

A mission is a typed work graph. You declare:

• Objective: Enumerate subdomains for example.com and check for subdomain takeover.
• Tools allowed: DNS enumeration, HTTP probing, certificate transparency logs.
• Egress: example.com and public CT log endpoints.
• Exploitation: None. Findings only.

The runtime checks this at submit time. If the agent tries to add a tool (say, a SQL injection scanner), the runtime refuses. If the agent tries to connect to an undeclared endpoint, the microVM blocks egress.

This is not a prompt. It is a schema. The agent cannot talk its way out of the mission scope.

Grant Model: Delegated Permissions, Not Vibes

An agent does not have permissions. It has a grant from a named person. The grant says:

• Who delegated it: [e-mail]
• What the agent can act as: Read-only access to the bug bounty program's scope list.
• Budget: 1000 tool calls, 10 hours of compute.
• Expiration: 7 days.

If the agent exhausts the budget or the grant expires, the runtime stops dispatching work. The agent cannot renew its own grant. A human must.

This prevents an agent from escalating privileges by discovering a new credential. The grant is not derived from what the agent finds. It is derived from what a human delegated.

Observability: Replay Any Run, Move by Move

Every agent action writes to the timeline. You can replay any run:

1. Agent submitted mission recon-example-com.
2. Runtime dispatched dns-enum tool in microVM vm-4f3a.
3. Tool returned 47 subdomains.
4. Agent submitted http-probe tool for each subdomain.
5. Runtime blocked 3 tool calls: egress to internal.example.com not in mission scope.
6. Agent found subdomain takeover on dev.example.com.
7. Agent proposed exploitation. Runtime blocked: mission scope is findings only.

The replay is not a log dump. It is a reconstructed execution graph. You see what the agent saw, what it decided, and where the runtime intervened.

This matters for compliance. If an agent accidentally scans a production system, you can show the auditor that the runtime blocked the action and that the mission scope did not include production.

Failure Modes and Mitigations

Agent discovers a credential and tries to use it elsewhere. The microVM has no persistent state. The credential is written to the knowledge graph, but the agent cannot use it without a new mission that includes the target system in scope.

Agent finds a critical vulnerability and the runtime blocks exploitation. Correct behavior. The human reviews the finding, decides whether to exploit, and submits a new mission with exploitation in scope.

Agent exhausts its budget before finishing reconnaissance. The runtime stops dispatching. The human reviews the partial results, decides whether to extend the budget, and resubmits the mission.

Tool has a bug and crashes the microVM. The runtime logs the crash, marks the tool call as failed, and continues the mission. The agent can retry or skip the tool.

Agent tries to exfiltrate data by encoding it in DNS queries. The microVM egress policy blocks DNS queries to undeclared resolvers. If the agent uses an allowed resolver, the query is logged. The timeline shows the exfiltration attempt.

Integration: Bringing MCP Tools Into the Runtime

Gibson includes Bridge, an Apache-2.0 component that brings any MCP-compliant tool in as a component. MCP (Model Context Protocol) is Anthropic's standard for tool calling. If you have an MCP tool, Bridge wraps it and exposes it to the runtime.

The runtime still enforces the mission scope and egress policy. The MCP tool runs in a microVM. It cannot see the runtime or other tools. The only difference is that you do not have to rewrite the tool to fit Gibson's API.

This matters for offensive security. Most recon tools (subfinder, nuclei, ffuf) are not MCP-native. You wrap them once with Bridge, and the runtime enforces the same controls as native Gibson tools.

Deployment Shape: Air-Gapped, Per-Client Isolation, or Multi-Tenant

Gibson targets environments where agent security is not optional:

• Defense and national security: Air-gapped, no egress. The runtime runs on-premises. Agents cannot phone home.
• Federal and public sector: Inside your authorization boundary. The runtime does not cross accreditation boundaries.
• Financial services: Every action attributable. The timeline is the audit log.
• Consultancies and MSSPs: Per-client isolation, white label available. Each client gets a separate knowledge graph and timeline.

The runtime does not assume internet access. It does not assume a shared control plane. It assumes that the environment is hostile and that agents are untrusted.

Code Example: Submitting a Mission with Egress Policy

from gibson import Runtime, Mission, Tool, EgressPolicy

runtime = Runtime(endpoint="https://gibson.internal")

mission = Mission(
    objective="Enumerate subdomains for example.com",
    tools=[
        Tool(name="dns-enum", egress=EgressPolicy(
            allowed=["8.8.8.8", "1.1.1.1", "*.crt.sh"]
        )),
        Tool(name="http-probe", egress=EgressPolicy(
            allowed=["*.example.com"]
        ))
    ],
    scope=["example.com"],
    exploitation=False,
    budget={"tool_calls": 1000, "compute_hours": 2}
)

grant = runtime.get_grant(agent_id="recon-agent-01")
result = runtime.submit(mission, grant)

# Runtime checks:
# 1. Is the mission schema valid?
# 2. Does the grant allow this mission?
# 3. Are the tools declared and egress policies sane?
# If yes, dispatch. If no, reject before any tool runs.

The runtime validates the mission before dispatching any work. If the agent later tries to add a tool or change the egress policy, the runtime refuses.

Technical Verdict

Use Gibson ADK when:

• You are building offensive security agents that must run reconnaissance or vulnerability scanning at scale.
• You need to enforce security boundaries at the tool layer, not just the prompt layer.
• You need a replayable audit log for compliance or incident response.
• You are deploying agents in air-gapped, multi-tenant, or high-assurance environments.

Avoid it when:

• Your agents do not need to run untrusted code or access sensitive systems.
• You are building conversational agents that do not execute tools.
• You do not need per-tool egress control or microVM isolation.
• You are prototyping and the overhead of mission schemas and grants slows you down.

The runtime is not a general-purpose agent framework. It is a security boundary for agents that run offensive security workflows. If your agent needs to scan a network, enumerate attack surfaces, or exploit vulnerabilities, Gibson enforces the controls that prevent it from pivoting into production systems or leaking credentials. If your agent just needs to answer questions, the overhead is not worth it.

---

Source Links

• Primary source: zeroroot.ai
• Discussion: Hacker News