Agent-readable docs index: /llms.txt. Full docs in one file: /llms-full.txt. Download /docs.zip to grep all markdown files locally.

Security administration

Stackyapper keeps workspaces separate, encrypts connected-app credentials, checks current permissions before each tool call, and records operational activity; your security posture still depends on the identities, provider scopes, app connections, and tool access your organization chooses.

Before you connect an AI client

  1. Select the correct company or customer workspace.
  2. Connect the app using a provider account limited to the intended tenant and provider-side permissions.
  3. Grant the smallest useful set of read tools to a test group or user.
  4. Add restrictions for operations that group must never use.
  5. Review Effective access for the test user.
  6. Connect one AI client, then verify a first call in Audit.
Connecting an app and granting access are separate decisions. An available app does not automatically become available to every person or AI client. Every tool call passes the same six-layer evaluation, from authentication through safety confirmation, at execution time.

Customer security features

  • App and tool access — group and direct grants, plus restrictions that grants cannot override.
  • Confirmation — exact-call approval for higher-impact actions when required by policy.
  • Security email — immediate alerts, daily summaries, weekly summaries, and verified shared recipients. No email contains tool arguments, returned data, or credentials.
  • Location and network context — expected-country settings and full, truncated, or disabled client-address retention.
  • Audit — activity filters, investigation details, and CSV export.
  • Revocation — independent removal of clients, API keys, sessions, grants, connections, and memberships.
  • Managed identity — managed SAML and Microsoft Entra SCIM on Business workspaces.

AI client allow and block rules

Client admission is in beta and is available to owners and admins of a non-managed workspace. It lets them:
  • Require approved clients instead of accepting every valid OAuth registration.
  • Allow or block exact OAuth identities and reviewed product profiles.
  • Keep direct API-key clients disabled or enable them separately with an explicit warning.
  • Revoke the current direct API key when rotating it.
Client admission does not replace user, workspace, app, or tool permissions. A client that is allowed to connect can still use only what the member is allowed to use.

Read and change permissions

Read-only tools run when the current identity has permission. Tools that create, change, delete, move money, or handle sensitive credentials can receive stricter policy and may require confirmation for that exact call — not a standing approval for future changes. Do not grant a broad write-capable app merely because some of its actions ask for confirmation. See Understand access.

Audit history

Stackyapper records who called which tool, through which client, in which workspace, and with what result. Routine audit records do not store tool arguments or data returned by the connected app. After every first connection or material permission change, follow the verification ritual in Audit and investigation, and test a restricted tool to confirm it is denied at execution.

Credential handling

  • Provider secrets are encrypted at rest.
  • Interactive clients should use OAuth.
  • API keys are shown once and should be stored in a secret manager.
  • Provider credentials remain separate from the token used by the AI client.
  • Clients, grants, sessions, API keys, and provider credentials can be revoked independently.
Use a provider identity dedicated to the intended business purpose when the provider supports it. Limit its tenant, role, and scopes at the provider as well as in Stackyapper. Reconnect or rotate it when its owner changes, its scope is no longer appropriate, or compromise is suspected.
AI client OAuth access tokens are short-lived and authorization grants expire; see Lifecycle & API keys for the lifetime table. A user or workspace admin can revoke access at any time.

Revoke access

Choose the narrowest response that contains the issue:
  • Remove one tool grant or add a restriction when a capability is no longer needed.
  • Revoke an AI client or API key when that client should no longer connect.
  • Remove or rotate the provider credential when the provider account may be compromised.
  • Remove workspace membership when the person should no longer reach any workspace resources.
When a person leaves the organization, follow the canonical offboarding procedure in Users and groups.

If you suspect misuse

  1. Revoke the affected AI client, API key, session, grant, or provider credential.
  2. Review Audit with the narrowest workspace, time, app, result, and client filters that identify the activity.
  3. Compare the activity with the connected provider's own authorization and service logs.
  4. Rotate affected provider credentials and review provider-side sessions.
  5. Report a suspected Stackyapper vulnerability or incident to security@stackyapper.dev.
Do not paste tokens, provider secrets, cookies, complete tool arguments, or returned business data into a support request.

Shared responsibility

Stackyapper protects the gateway, stored credentials, workspace boundaries, and tool authorization. Your organization remains responsible for its identity provider, provider-side scopes, access decisions, and review of the activity record.
Read the public Trust Center and complete security model for infrastructure, retention, incident response, certification status, and data-processing details.
Open the portal
Review apps, users, AI clients, and audit activity for your workspace.
Powered byHolocron