Skip to content
docs

Limits: connectors, the vault and egress

The limits of connectors, the credential vault and network egress, and of the GitHub, Slack, Stripe and Gmail connectors.

Connectors, the vault and egress (S16)

Section titled “Connectors, the vault and egress (S16)”
  • Go can’t reliably zero memory. The vault zeroes the data keys and decrypted bytes it holds, but the garbage collector may have copied them, and HTTP header values are strings (VAULT.md).
  • A vault key plus a database dump reads every credential. Rotation can’t un-leak a key: rotate and replace the upstream credentials.
  • The vault doesn’t protect against a compromised Deedglass process or the upstream service itself, and it has no rollback protection: restoring an older, consistent credential row brings the older credential back.
  • No KMS yet. The key ring lives in DEEDGLASS_VAULT_KEY; a KMS-backed key provider is v2.
  • Egress sees addresses, not intent. Misuse of an allowed API is policy’s job (NETWORK_EGRESS.md).
  • No HTTP proxy support for connector traffic, and no per-connector trust roots for private APIs (v2).
  • A REST write without a read-back stays at L0: a service that answers 200 without saving is L0 · VERIFIED. Add a readback to the tool to reach L1 (WITNESS.md).
  • sensitive args are redacted from outputs and logs, not digested in the action row (S22). An org in PHI mode stores ids and digests of every argument once the action is sealed.
  • Credentials aren’t cached. Every call reads its credential row (one indexed read); a 30 s cache is a stretch item, taken only if the benchmark asks for it.
  • The MCP HTTP gateway’s upstreams still take their headers from the environment (S15’s mcp.upstreams), not from the vault; their connections already go through egress. Moving them to mcp_http connector rows is S18 carry-over.
  • /mcp/native serves the built-in tools only. An org’s REST connectors are called through POST /v1/actions; listing them as MCP tools comes later.

GitHub, Slack and approvals in Slack (S29)

Section titled “GitHub, Slack and approvals in Slack (S29)”
  • L1, not L2. GitHub and Slack writes are read back from the service’s own API (L1). That shows what GitHub and Slack report now, not whether the change was wise, and not a system-of-record change stream.
  • The GitHub marker is visible. Issue, comment and pull request bodies end with <!-- deedglass:act_… --> (hidden when rendered, visible in the raw body). issue_marker: false removes it, and with it the reconciliation of an uncertain create.
  • An uncertain GitHub create is looked up once. When a create times out after sending, the connector reads the newest items once; if the marker isn’t there yet, the action is UNVERIFIABLE (“It may have run”), never retried.
  • GitHub REST only. No GraphQL, no Actions runs, no org administration; GitHub Enterprise Server is untested. File paths must be ASCII or contain no combining marks (a conservative NFC check without a Unicode library).
  • Slack identity is the workspace’s word. A Slack user maps to a person by an email Slack reports as confirmed. Use an SSO workspace and approvals.require_email_domains; a compromised Slack account can approve like a compromised Console session.
  • Slack sees the card. The summary, the rule, the reason and the arguments (sensitive ones as digests) are sent to Slack.
  • One approvals channel per org, a public URL. No per-rule channels and no Socket Mode yet; Slack must reach POST /v1/slack/interact over HTTPS.
  • Cards can lag. An edit is a job that retries 4 times; after that the card says nothing new and the Console is the source of truth.

Stripe and Gmail (S30)

Section titled “Stripe and Gmail (S30)”
  • Stripe sandboxes only. Live keys are refused and a live-mode answer disables the connector. There is no switch: live mode needs a founder-approved ADR and its own review.
  • L1 shows Stripe’s record, not whether the refund was right.
  • Stripe’s own approvals are invisible. A refund Stripe holds for an agent-tagged key’s approval rule is UNVERIFIABLE; Deedglass doesn’t poll for the outcome yet (a reconcile job is a stretch goal).
  • The refund budget counts USD. The starter’s refunds-per-day measures USD refunds Stripe confirmed; other currencies go to a person.
  • Drafts only is Deedglass’s rule, not Google’s. The gmail.compose scope itself permits sending; Deedglass enforces drafts only in code (no tool, an endpoint allow-list, a source test).
  • Google apps in Testing need re-authorization every 7 days.
  • No attachments, labels or deletes in Gmail, and HTML bodies are stored, never rendered.
  • Notion writes plain paragraphs under the listed parent pages only (S31). No databases, data source rows, files, comments, edits or deletes; the read-back compares plain text, not rich formatting; Notion has no idempotency key, so a create whose answer was lost is UNVERIFIABLE and is never sent again.

More limits

Section titled “More limits”