Skip to content

Security and access checklist

Outcome

You will keep project access, connectors, MCP credentials, exports, and administrative settings within the intended tenant boundary.

Before you begin

  • Identify the project owner and the person responsible for each connector.
  • Use a separate test project for a new integration or write-back policy.
  • Never put production secrets, access tokens, API keys, customer data, or internal service URLs in documentation, screenshots, tickets, or chat.

Confirm the data boundary

Threadory scopes knowledge, activity, approvals, exports, API keys, and MCP connections to a project. API requests verify project membership and filter data by the selected project.

  1. Open the project switcher and confirm the intended organization and project.
  2. Open Settings → Members and review every assigned role.
  3. Remove access that is no longer needed.
  4. Keep at least one owner; assign a replacement before removing or demoting the last owner.
  5. Use separate projects when data or access must not be shared.

Organization access is first-class org_membership (ADR-0006); do not assume that an organization role grants the same role in every project — data access is still per-project membership.

Apply least privilege

Use the lowest role that supports the person's task:

  • Viewer — read project data and default viewer-level governance tabs;
  • Member — contribute and request project actions;
  • Admin — manage connectors, settings, API keys, exports, and approvals;
  • Owner — change roles, organization access controls, and destructive project or organization settings.

An owner can open Settings → Organization → Access control and set a minimum role for Cost, Audit Log, Prompts, LLM, and API Keys. Cost, Audit Log, and API Keys have dedicated server-side read checks. Treat tab visibility as navigation, not as the only security boundary; settings mutations still require their server-enforced role.

Protect connector identity

  1. Grant only the scopes listed in the connector guide and the integration matrix.
  2. Use a dedicated service identity where the connector supports it.
  3. Keep OAuth credentials and webhook secrets in Threadory's secret flow, not in free-text fields.
  4. After connecting, run the guide's read-only or low-risk verification.
  5. Before disconnecting or rotating a credential, review pending approvals and automatic workflows that depend on that identity.
  6. Revoke the old credential in the source system after the replacement is confirmed.

Disconnecting a source stops future access but does not automatically prove that already synced entities, audit records, or exports have been deleted. Use the documented export and retention process for data lifecycle requirements.

Protect MCP and API keys

  1. Prefer OAuth for a human's interactive MCP client.
  2. Generate a project API key only for a named headless integration.
  3. Copy the plaintext once into an approved secret store.
  4. Never place the key in an MCP URL, source control, screenshots, or prompts.
  5. Review Last used in Settings → API Keys.
  6. Revoke unused or suspected keys immediately, then replace the consuming integration.

An API key is bound to one project. OAuth MCP access follows the user's current project membership and role.

Offboard a user or integration

  1. Identify the projects, connectors, API keys, and pending approvals in scope.
  2. Export required records before destructive retention or connector cleanup.
  3. Revoke named API keys and source-system credentials.
  4. Remove or lower project membership.
  5. Disable automatic write-back that no longer has a responsible reviewer.
  6. Verify that old credentials receive 401 or 403 and that valid users still have access.
  7. Record the change in the organization's approved change log.

Respond to a suspected credential leak

  1. Revoke or rotate the credential first.
  2. Do not paste the leaked value into an incident ticket.
  3. Search Audit Log by actor and time, and correlate with Activity.
  4. Check the source system's own audit history.
  5. Replace the credential only after confirming the intended project and minimum access.
  6. Escalate to the platform operator when cross-project access, unknown activity, or unavailable audit evidence is suspected.

Verify the result

  • A removed user cannot open the project.
  • A revoked API key stops working immediately.
  • A viewer can read but cannot resolve approvals or change settings.
  • Connector and MCP requests return data only for their bound project.
  • Required audit and export evidence is stored in an approved location.

Common problems

Symptom Likely cause What to do
A user sees a sensitive settings tab The owner configured a low minimum role Review Organization → Access control and the role matrix
A hidden tab's API still behaves differently than expected Tab visibility and endpoint authorization are separate controls Test with the intended role and report any server-side authorization gap
An API key value cannot be recovered Plaintext is intentionally shown only once Revoke it and generate a replacement
Disconnecting did not remove historical knowledge Connector removal is not data deletion Apply the approved export and retention process
A rotated source credential breaks writes The connector still uses the old identity or lost scopes Reconnect, verify minimum scopes, and test a safe action
Project data appears in the wrong context The wrong project was active or a boundary defect is suspected Stop work, preserve evidence, and escalate without copying customer data into the ticket

Next step

Review members and roles, then configure audit, export, and retention.