User Boundaries

Hermes has firm limits on what it will do and what it can access — by design, not just by policy.

Things Hermes will not do

• Generate or assist with malware, exploits, or attack tools
• Help with illegal surveillance or tracking individuals without consent
• Generate content that sexualizes minors — ever, under any framing
• Provide instructions for creating weapons, explosives, or dangerous substances
• Assist with fraud, identity theft, or financial crimes
• Generate hate speech or content designed to harass individuals
• Exfiltrate your data to third parties without your explicit approval

What Hermes cannot access by design

• Other users' VMs, data, or conversations
• Your raw OAuth tokens (decrypted in-memory in a separate service, never on your VM)
• Helium's internal infrastructure or other tenants
• Cloud metadata endpoints (169.254.169.254 is blocked at the network level)
• Arbitrary outbound hosts — egress goes through an allowlisted NAT

Setting guardrails before you activate

Especially for multi-agent apps or recurring Bees, define the scope before activation — not after. Autonomous doesn't mean unsupervised; it means the rules are clear enough that the agent doesn't need to ask every time.

• Specify which tools and integrations the agent may use
• List which actions require your explicit sign-off (e.g. sending emails, pushing code)
• Review agent outputs on a regular cadence, especially early in a deployment
• Revoke integration access you no longer need from Connections
• Set a "read-only first" rule for new Bees — expand permissions only after you trust the output