Skip to content

Forum

AI Assistant
Notifications
Clear all

Isolated Goose agents on air-gapped hardware - lessons learned.

1 Posts
1 Users
0 Reactions
0 Views
(@api_sec_analyst)
Eminent Member
Joined: 1 week ago
Posts: 17
Topic starter
Translate
English
Spanish
French
German
Italian
Portuguese
Russian
Chinese
Japanese
Korean
Arabic
Hindi
Dutch
Polish
Turkish
Vietnamese
Thai
Swedish
Danish
Finnish
Norwegian
Czech
Hungarian
Romanian
Greek
Hebrew
Indonesian
Malay
Ukrainian
Bulgarian
Croatian
Slovak
Slovenian
Serbian
Lithuanian
Latvian
Estonian
  [#1227]

Our team recently completed an internal security audit for a deployment of Goose agents on purpose-built, air-gapped hardware. The primary goal was to enforce a strict zero-trust posture where the agents could process sensitive documents without any egress capability. While the extension model's local execution is a significant advantage, we identified several nuanced risks in credential handling and the local API surface.

Key findings from the audit:

* **Local API Exposure:** The agent's local HTTP server, while necessary for extension communication, becomes a critical attack surface. Without network-level controls, a compromised extension could potentially interact with other agents or system services via localhost.
* Recommendation: Implement mandatory binding to a Unix domain socket instead of a TCP loopback, and apply filesystem-based access controls.
* **Credential Persistence in Memory:** The audit revealed that OAuth tokens and API keys, fetched before air-gapping, remain in the agent's process memory for the session duration. A memory dump or a sophisticated local extension could exfiltrate these.
* We developed a pattern for short-lived, task-specific credential injection, invalidating them immediately after use, even within the isolated environment.
* **Extension Supply Chain Integrity:** "Open-source" does not equate to "vetted for air-gapped use." We found extensions with latent dependencies that attempted non-malicious but prohibited actions (e.g., DNS lookups for time servers).
* This necessitates a pre-deployment analysis phase: static analysis of all extension code and its dependency tree, followed by dynamic sandboxing on an identical, network-isolated test rig.

The most effective technical control was implementing a mandatory configuration wrapper that enforces constraints before the Goose core initializes. For example:

```yaml
# security_context.yaml
enforce:
network: deny_all
bind_address: unix:///run/goose/agent.sock
allowed_syscalls:
- read
- write
- open
max_memory_mb: 512
credential_ttl: 300 # seconds
```

This shifts the security model from "hoping extensions behave" to "enforcing a security context the platform cannot violate." The open-source nature was ultimately beneficial, as we could verify these controls were in place and had not been subverted. The lesson is that isolation is not just a network rule; it must be a holistic runtime and configuration discipline applied to the agent host itself.


Every API endpoint is a threat surface.


   
Quote