Integration permissions

Why scope matters

Integrations work because you grant Ochre access to data in third-party services. The right approach is the principle of least privilege: Ochre should only be able to do what we strictly need to deliver the feature, and nothing more.

Every integration has explicit scopes. We document them. We don't request "all read, all write" tokens when "read this one resource" is enough.

Stripe

Scopes: read_only end-to-end (via Stripe Connect).

What we can do:

• Read customers, subscriptions, prices, products, invoices.
• Listen to webhooks for those resources.

What we cannot do:

• Create charges. Issue refunds. Cancel subscriptions. Update payment methods. Modify any resource.
• Even if our token were leaked, no money could move.

This is the most important security property of the Stripe integration: read-only is enforced by Stripe's API, not by Ochre's code.

HubSpot

Scopes: Read on contacts, companies, and deals. Webhook subscription on contact changes.

What we can do:

• Read contact fields (email, name, lifecycle stage, lead status, job title, company, last contacted).
• Read deal fields (name, stage, amount, owner) for context.
• Receive webhook updates when those change.

What we cannot do:

• Create or update contacts, companies, or deals.
• Read other object types we haven't requested (engagements, tasks, custom objects).
• Access HubSpot Marketing Hub, Service Hub, or CMS data unless explicitly scoped (we don't request these).

Linear

Scopes: Read issues, comments, teams, projects. Write issues and comments.

What we can do:

• Read your Linear teams, projects, and issues.
• Create new issues from Ochre conversations.
• Post comments on linked issues.
• Receive webhook updates on issue and comment changes; status changes on a linked issue feed back to the conversation.

What we cannot do:

• Delete issues or comments.
• Modify team membership or project settings.
• Access organization-level admin features.

GitHub

App permissions: Issues (read & write), Pull requests (read), Metadata (read).

What we can do:

• Create issues in repos you've granted access to.
• Comment on those issues.
• See PR metadata (titles, statuses, references) for the same repos.

What we cannot do:

• Read your source code. We don't request contents permission.
• Modify PRs, merge them, or push code.
• Access repos you didn't grant access to.
• Manage your GitHub organization or team settings.

The GitHub App model means access is per-repo, not account-wide. You explicitly choose which repos Ochre can see.

Slack

Scopes: channels:read, chat:write, chat:write.customize, commands, users:read, plus the equivalents for groups and Connect channels Ochre is added to.

What we can do:

• See channels and Connect channels Ochre is added to.
• Post replies in those channels — under your workspace's logo and brand name (see Per-workspace Slack branding).
• Handle /ochre slash command invocations.
• Read user info to attribute messages.

What we cannot do:

• Post in channels Ochre isn't a member of (chat:write.public is not requested).
• Read DMs Ochre isn't part of.
• Modify Slack workspace admin settings.

OAuth security

All OAuth flows are CSRF-protected with signed state and validate that return_to is a same-origin URL on Ochre, preventing open-redirect abuse where an attacker redirects you to a malicious destination after authorization.

Token storage

OAuth access tokens, refresh tokens, and signing secrets for every integration are stored encrypted at rest in the database. The cleartext token is never exposed through normal table reads — even our own product code can't SELECT access_token FROM org_integrations and get a usable value back.

Reads go through a dedicated server-side function (get_integration_token) that:

1. Checks the caller is an Owner or Admin of the workspace.
2. Decrypts the token in a privileged context.
3. Returns the cleartext to the calling code path.

Agent-role users cannot retrieve a token, even from internal endpoints. A leaked database snapshot, on its own, doesn't yield usable tokens.

Inbound webhook security

Inbound webhooks from Stripe, HubSpot, Linear, GitHub, and Slack are signature-verified before we accept them. This is an internal hardening, not a configuration step you take. You don't need to set anything up; we just don't trust unsigned events. Ochre does not currently expose outbound webhooks to customers.

Token rotation

If you suspect a token has been compromised:

1. Disconnect the integration in Ochre. The encrypted token row is cleared.
2. Revoke on the third-party side as well (see per-integration steps in Disconnecting integrations).
3. Reconnect. A fresh token is issued and stored encrypted.

There's no penalty for being paranoid.

What's next

• See Security overview.
• For specific integrations: Stripe, HubSpot, Linear, GitHub, Slack.