Envelope

Security & privacy

Envelope is primarily a definition layer, not a data layer. For Paperclip and Relevance AI deployments, your agents run on your infrastructure and Envelope only ever receives aggregated usage counts — never your prompts, responses, or user data. Amazon Bedrock deployments using the proxy invoke endpoint have a different posture, covered in detail below.

How it works

Envelope's role is to store team definitions and broker deployments. When you deploy a team, Envelope provisions the agent hierarchy into your chosen platform — then steps back. From that point forward, all execution happens on your infrastructure or your platform provider's infrastructure, depending on which platform you chose.

The key principle: Envelope defines what your team does. It does not participate in what your team processes. The definition (agent names, prompts, structure, tools) lives in Envelope. The runtime data (user inputs, LLM outputs, conversation history) never does.

Paperclip — self-hosted path

Zero-data architecture · Self-hosted

Paperclip is a self-hosted orchestration server you run on your own infrastructure. When you deploy a team to Paperclip, this is the complete data flow at runtime:

  1. Your Paperclip server receives a user task and determines which agent to invoke. Touches your server only.
  2. Paperclip CLI (local) calls the LLM API directly — the prompt goes from your machine to your LLM provider, not through Envelope. Touches your machine → LLM provider.
  3. LLM response returns directly to your CLI, which feeds the result back to Paperclip. Touches LLM provider → your machine.
  4. Billing webhook — after a run completes, Paperclip sends Envelope a lightweight event: run count + token total only. Touches your server → Envelope.

What this means for your data: Prompts, user inputs, LLM responses, and conversation history never transit through Envelope's servers. Your LLM API key stays on your machine. Envelope has no technical capability to access your runtime data because it is never sent there.

Relevance AI — managed cloud path

Platform-managed execution · Managed cloud

When you deploy to Relevance AI, your agents run on Relevance AI's managed infrastructure. Envelope provisions the agent structure into your Relevance AI workspace — then execution is handled entirely by Relevance AI's platform.

Data posture for Relevance AI deployments:

  • Envelope only provisions the team definition — agent names, prompts, tools
  • Runtime execution is managed by Relevance AI under their security controls
  • Runtime data (prompts, responses) is processed within Relevance AI's infrastructure, not Envelope's

Review Relevance AI's security documentation for their data handling policies.

For teams that require full data sovereignty — no third-party infrastructure handling runtime data — Paperclip is the appropriate choice.

Amazon Bedrock — proxy invocation path

Envelope proxies invocations · AWS

Bedrock works differently from Paperclip and Relevance AI. Because AWS Bedrock has no native webhook or push mechanism, Envelope provides an optional proxy invoke endpoint that relays calls to your deployed Bedrock agent on your behalf — using the AWS credentials you provided at install time.

  1. Your application sends a request to Envelope's proxy endpoint — authenticated with your Envelope API key. Touches your app → Envelope.
  2. Envelope server loads your stored AWS credentials (encrypted at rest), calls your Bedrock agent on your behalf, and streams the response back. Touches Envelope → AWS Bedrock.
  3. Bedrock response — Envelope collects the response, records the run for observability, then returns the result. Touches AWS Bedrock → Envelope → your app.

What this means for your data:

  • Your input text and agent response text transit Envelope's server — this is different from Paperclip. Envelope sees the content of the invocation.
  • Your AWS credentials are stored encrypted in Envelope's credential vault so the proxy can use them. They are never returned in any API response.
  • Envelope does not log or persist the content of invocations. Only the run count, token totals, and success/failure flag are recorded.
  • AWS CloudTrail will show InvokeAgent calls from Envelope's infrastructure IP — this is expected and auditable.

Prefer a zero-proxy option? You can invoke Bedrock directly from your own code using the AWS SDK, then self-report the run to Envelope using the runs API endpoint. This keeps your LLM traffic entirely within AWS — Envelope only receives the token count and status.

Billing events

Per-run and per-token pricing requires Envelope to receive usage data so builders can earn royalties. This is done through a lightweight billing webhook — designed from the start to contain only what's needed for accounting, nothing more.

What a billing event contains:

  • Install ID (which deployment)
  • Template ID (which team)
  • Run count
  • Token total (input + output)
  • Success / failure flag
  • Timestamp

What it never contains:

  • Prompts or system instructions
  • LLM responses or completions
  • User inputs or conversation history
  • Tool call arguments or results
  • API keys or credentials
  • Any user-identifiable data

Think of it the same way you think about a SaaS invoice line item — "500 API calls in March" — not the content of those calls. That's the level of detail Envelope receives.

What Envelope does and doesn't see

| Data type | Envelope sees it? | Notes | |---|---|---| | Team definition (agents, prompts) | Yes — always | Stored by Envelope so it can be deployed | | Platform credentials | Bedrock only — encrypted | Paperclip/Relevance AI credentials are not stored. Bedrock credentials are stored encrypted so the proxy invoke endpoint can use them. | | User inputs / tasks | Bedrock proxy only | Paperclip & Relevance AI: never transits Envelope. Bedrock via /invoke: passes through Envelope's server. | | LLM responses | Bedrock proxy only | Paperclip & Relevance AI: returned directly to your runtime. Bedrock via /invoke: passes through Envelope's server. | | Token counts | Yes — aggregated only | Per billing event, no per-call granularity | | Run counts | Yes — aggregated only | Used to calculate royalties for the builder | | Success / failure rate | Yes — boolean per run | Used for observability dashboard, no content attached |

Enterprise posture

For enterprise teams with strict data residency or sovereignty requirements, the Paperclip path provides a genuinely air-gapped runtime:

  • On-premise orchestration — Paperclip runs on your servers. It never needs to call home to Envelope at runtime — only for billing events.
  • Direct LLM API calls — your CLI calls your LLM provider directly using your own API keys — whether that's Anthropic, OpenAI, Google, Mistral, or any other. The requests route from your network, not Envelope's.
  • Your keys, your control — API keys and secrets are injected at deployment time into your Paperclip instance. Envelope never stores them.
  • Audit-friendly billing — the billing webhook payload is fixed, minimal, and inspectable — no opaque blobs. You can log and verify exactly what's sent.
‹ All guidesDocs ›