rappidAI Ghost. Security, under the hood.

An integrated security runtime for autonomous AI agents. Ghost combines isolation, deception, prompt-injection signals, scoped approvals, runtime limits and evidence behind one simple execution flow.

View on GitHub v0.3.0 Release

ghost · SHADOW

ghost run -- sh -c 'cat ~/.aws/credentials'
ghost inspect latest
ghost graph latest
ghost incidents latest

v0.3.0 · Released · Experimental · Apache-2.0

One command. Multiple security layers.

Ghost wraps agent execution in one controlled runtime. It preflights the environment, isolates the process, keeps protected host resources out of reach, inspects selected untrusted instruction surfaces, enforces network and resource boundaries, and records evidence for later inspection.

For developers, security engineers and researchers who want autonomous agents to stay useful without silently inheriting broad trust. Most complexity stays underneath ghost run; advanced evidence remains available through inspect, graph and incidents when needed.

Get started

ALLOW. DENY. SHADOW. ASK.

Runtime enforcement is deterministic and never delegates authorization to an LLM. The Prompt-Injection Guard contributes bounded security signals and trust context, but a detector result can never make a forbidden operation safe or disable isolation.

ALLOW

The permitted real resource or exact destination is available under the active policy.

DENY

Access is refused. Hard runtime, host and containment boundaries remain non-approvable.

SHADOW

Ghost exposes controlled synthetic material while the corresponding protected host resource remains isolated.

ASK

For explicitly configured destinations only, Ghost can pause one exact operation for a narrow user decision. Unavailable or malformed interaction becomes DENY.

Why a decoy can tell you more than a refusal.

Suppose a process tries to open ~/.aws/credentials. With the default Shadow Home policy, it receives a fresh synthetic credential file inside /home/ghost—not the host user's credentials. Ghost does not check, copy or derive values from the real file. Synthetic AWS values, the nonfunctional SSH-key-shaped file and the generic .env decoy cannot authenticate to real services.

01
Prepare
Create session-private decoys and confirm the separate inotify sentinel is watching before the command starts.
02
Observe
Record DECOY_ACCESS when an open/access event is observed for an explicit decoy file.
03
Contain
With on_decoy_access.network: deny, publish containment and fence subsequent gateway allow decisions through the sentinel queue.
04
Inspect
Use the event timeline, provenance graph and incidents to see the supported sequence with evidence references.

A decoy access is evidence of a file event, not proof of malicious intent or credential exfiltration. Containment does not revoke already-authorized, established connections.

v0.3.0 · 2026-09-21

v0.3.0 turns Ghost into an integrated agent-security runtime.

The release keeps the same two-command workflow while adding context, approval, runtime protection and stronger evidence underneath it. The existing v0.2 isolation and network boundary remain authoritative.

Integrated Prompt-Injection Guard	Before PROCESS_START, Ghost inspects bounded agent-facing workspace surfaces such as AGENTS.md, documentation and selected scripts. Findings are minimized rule/category/hash signals, not copied document bodies, and both false positives and false negatives remain possible. Read the implementation boundary
Trust context without invented causality	Selected workspace sources are classified deterministically and linked into provenance as observed or derived context. Ghost can reconstruct that suspicious instructions preceded later activity without claiming that the content caused the agent to act. Read the implementation boundary
ALLOW / DENY / SHADOW / ASK	Exact configured HTTP/HTTPS destinations may require ALLOW_ONCE, ALLOW_SESSION or DENY. Approval is session-local and exact to scheme, host, port and method; containment and hard-forbidden destinations always take precedence. Read the implementation boundary
Integrated runtime resource protection	The agent and descendants run with mandatory memory, CPU, PID, temporary-storage and session-time ceilings. v0.3 defaults to 2 GiB RAM, one CPU, 256 processes/threads, 64 MiB /tmp and a one-hour deadline with bounded termination and cleanup. Read the implementation boundary
Automatic secure preflight and summaries	ghost run verifies Docker, identity, policy, workspace and session-owned state before PROCESS_START. Successful checks stay quiet; security-relevant sessions end with concise summaries derived from persisted evidence. Read the implementation boundary
Adversarially validated release	The final audit fixed approval, containment, HTTP framing, evidence-finalization, recovery and rapid child-OOM edge cases. GhostBench now contains 25 named scenarios and the release gate recorded 25 PASS, 0 FAIL and 0 SKIP. Read the implementation boundary

One runtime. Integrated security context.

Ghost routes workspace observations, policy decisions, runtime enforcement and evidence through one session lifecycle. Prompt findings enrich context; policy and hard runtime boundaries remain authoritative; stored events feed provenance, incidents and summaries.

Isolation: Ephemeral Docker sessions expose the selected workspace and synthetic home, not the real home, Docker socket or Ghost database.
Prompt & trust context: A bounded pre-run guard inspects supported instruction surfaces and records content-minimized findings plus deterministic trust context. It is a signal layer, not an authorization authority.
Policy: Strict ghost.yaml validation applies deterministic ALLOW, DENY, SHADOW and intentionally scoped ASK decisions. Containment and hard forbidden targets override approval.
Deception: Fresh synthetic AWS, SSH and .env resources provide observable alternatives without reading or deriving values from real credentials.
Network & containment: Exact-hostname HTTP/HTTPS egress runs through a session gateway with resolved-address validation and live containment rechecks before authorization.
Runtime protection: Mandatory cgroup-backed memory, CPU and PID ceilings, bounded /tmp, read-only roots and a session deadline constrain the agent and descendants.
Evidence: SQLite retains minimized session events and security state. Required evidence failures fail closed rather than silently weakening the boundary.
Provenance / incidents: Deterministic reconstruction distinguishes observations, derived relationships and temporal ordering without inventing model intent or causality.
Human approval: Explicitly configured ASK destinations may pause for a narrow user decision; non-interactive, malformed or timed-out approval becomes DENY.
GhostBench: Twenty-five release-gated scenarios exercise isolated properties and integrated prompt/SHADOW/network, approval, timeout and session-isolation chains.

A hostname is not enough.

HTTP is restricted to port 80 and HTTPS CONNECT to port 443. github.com does not implicitly authorize api.github.com. Raw IPs, wildcards, single-label and local-use names such as host.docker.internal are rejected. IPv6 upstream egress is unsupported and fails closed.

Optional: replace only the network section in ghost.yaml. Keep deny unless limited egress is needed.

ghost.yaml · network

network:
  mode: allowlist
  allow:
    - github.com
  ask:
    - api.example.com

Resolution and containment details

Every returned IPv4 address must pass validation, including checks for unspecified/current-network, private, loopback, shared, link-local, protocol-assignment, benchmarking, multicast and reserved ranges. Empty, malformed, failed or mixed safe/prohibited DNS answers are denied. Connecting by the validated numeric address avoids a second hostname lookup. Each new request is checked again; Ghost does not claim to eliminate every DNS-rebinding technique or relay through an approved server.

The token/ack fence orders requests against decoy events already queued by inotify. A genuinely concurrent request whose barrier is ordered first can still be allowed. It is not packet-level atomic revocation and cannot end an already-established HTTP response or CONNECT tunnel. The Docker internal bridge remains a local link; services deliberately bound to that bridge are in the reachable set.

Network security

Start with a controlled local run.

Runtime-tested release target: Linux amd64 with Docker Engine, a working local Docker CLI/daemon and non-zero numeric host UID/GID. Linux arm64 binaries are cross-built and checksum-verified. Source builds need Git and Go 1.26.8 or a newer supported patch release. Docker Desktop on macOS is not release-qualified; native Windows execution is unsupported.

01
1. Build the released source
The tag selects released v0.3.0 rather than moving main. PATH is set for this terminal so the commands below resolve to the binary you just built. The reviewed release revision is linked below.
1. Build the released source
```
git clone --branch v0.3.0 --depth 1 https://github.com/rappidAI-Research/rappid-ghost.git
cd rappid-ghost
go build -o bin/ghost ./cmd/ghost
export PATH="$PWD/bin:$PATH"
ghost version
```
02
2. Initialize a clean demo project
These commands create a sibling ghost-demo directory. ghost init creates ghost.yaml, .ghost/ghost.db and .ghost/sessions/ without overwriting an existing configuration. Keep .ghost/ out of Git. For a real project, run init in that project's directory instead.
2. Initialize a clean demo project
```
mkdir -p ../ghost-demo
cd ../ghost-demo
ghost init
ghost run -- echo "hello from ghost"
```
03
3. Access a decoy and inspect the evidence
Run this in the demo directory. The cat command returns synthetic content. inspect shows the session timeline; graph and incidents reconstruct supported relationships. Both also accept --json. The -- separator for run is required.
3. Access a decoy and inspect the evidence
```
ghost run -- sh -c 'cat ~/.aws/credentials'
ghost inspect latest
ghost graph latest
ghost incidents latest
```

Already have Linux? The release also provides amd64 and arm64 binaries, so Go is not required for that route. Verify the downloaded binary against SHA256SUMS before execution.

Linux amd64 Linux arm64 SHA256SUMS

Ghost's pinned Alpine image is intentionally minimal: host-installed Python, Node or agent packages do not automatically exist inside it. Missing commands fail and never fall back to the host. The mounted workspace is intentionally visible to the agent, and attached program output is not sanitized, so do not place secrets there unless the agent is meant to access them.

GhostBench · v0.3.0

Twenty-five scenarios. Integrated security chains.

GhostBench is a reproducible security-property suite, not a security score. The v0.3.0 release gate ran all twenty-five required scenarios successfully on Linux amd64 with Docker, including integrated prompt/SHADOW/network, approval/containment, runtime-timeout and cross-session chains.

Release CI evidence GhostBench methodology

Recorded v0.3.0 release result · 21 September 2026

PASS: 25 · FAIL: 0 · SKIP: 0

v0.3 coverage includes hostile prompt signals with SHADOW access and later network denial, defensive-document false-positive control, non-interactive ASK failure closure, one-use and concurrent approval isolation, containment overriding cached approval, runtime timeout cleanup and integrated cross-session isolation.

GhostBench

ghost bench
ghost bench --require-all
ghost bench --scenario dynamic-containment

--require-all exits unsuccessfully on either FAIL or SKIP. Without Docker, Docker-dependent cases are SKIP, not PASS. The dynamic-containment demo uses a harmless local Docker HTTP fixture; it does not send credentials to an external service.

All twenty-five scenario identifiers

host-home-isolation
shadow-credentials
deny-sensitive-resource
network-deny
network-allowlist
direct-egress-bypass
dynamic-containment
session-isolation
fail-closed-runtime
safe-baseline
private-destination-blocked
environment-isolation
container-confinement
concurrent-containment
interrupted-session-recovery
prompt-injection-detected
prompt-guard-false-positive
untrusted-content-provenance
prompt-shadow-context
approval-unavailable
approval-once
approval-containment-precedence
concurrent-approval-once
cross-session-security-isolation
session-timeout

What Ghost does not guarantee.

Docker is still trusted	Docker, its daemon, the OCI runtime, pinned image and host kernel remain part of the trusted computing base. Ghost does not guarantee protection from every container escape or kernel vulnerability.
Prompt findings are heuristic	The integrated guard can miss attacks or flag benign text. It does not understand model intent and never authorizes access by declaring content safe.
Evidence is not causality	Provenance distinguishes observed events, derived exposure and temporal FOLLOWED_BY relationships. Ghost does not prove that suspicious content caused later behavior or that data was exfiltrated.
Network and resource controls are deliberately bounded	Ghost does not inspect TLS content, proxy general TCP/UDP, support IPv6 upstream egress, impose a byte quota on the workspace/evidence store, or provide aggregate host admission control. Established connections are not revoked retroactively.
Host and output boundaries still matter	Read-write mode intentionally permits workspace modification, and attached program output is not sanitized. Hard host/daemon failure can interrupt cleanup or evidence collection. Twenty-five passing scenarios demonstrate named properties, not universal attack prevention.

Inspect the source. Try the release.

v0.3.0 · 2184a0e87b7dca161267f5fe596a2dd5d56d189d

The documentation, binaries, checksums and twenty-five-scenario result below are pinned to released v0.3.0 at the audited release commit. Ghost remains experimental, and the linked security/threat documentation defines the precise boundary.

v0.3.0 release notes

View on GitHub v0.3.0 Release Documentation / README Security model

Architecture, policy and evidence references