Security and access control
Give AI access to the tools, not the keys.
Stackyapper keeps provider credentials out of AI clients and rechecks the person, workspace, app, exact tool, action risk, and any required confirmation before a request reaches your business system.
What risk does MCP access control reduce?
MCP access control software sits between AI clients and connected tools. It authenticates the caller, selects the correct workspace and provider credential, limits which tools can run, applies additional policy to higher-impact actions, and records enough metadata for administrators to review access.
MCP is the standard an AI client uses to request tools. Signing in protects the connection, but it does not decide which business system, credential, or operation that person should use. Stackyapper makes those decisions for its reviewed app catalog and checks them again when the tool runs.
What should MCP access control software enforce?
| Control | Question to verify | Stackyapper implementation |
|---|---|---|
| Caller identity | Is the inbound MCP request authenticated for this resource? | The MCP endpoint validates the caller before protected discovery or execution. |
| Workspace boundary | Which company or managed customer does this request belong to? | Users, connections, sessions, grants, and audit records resolve inside the selected workspace. |
| Credential ownership | Does the gateway keep inbound MCP tokens separate from provider credentials? | Stackyapper resolves a separately stored provider credential and does not forward the client token downstream. |
| Tool-level least privilege | Can an administrator grant one operation without granting the whole provider? | Service and individual tool grants are checked during discovery and again when a tool runs. |
| Action risk | Are reads, writes, deletes, financial actions, and credential-sensitive actions treated differently? | Each tool has reviewed risk metadata that feeds execution policy. |
| Exact confirmation | Is approval attached to the action and arguments the user actually reviewed? | Actions that require confirmation are authorized against the exact arguments before execution. |
| Tenant-safe transport | Can a provider URL reach private infrastructure or escape its authorized customer scope? | Provider requests use shared URL validation and public-network restrictions; workspace authorization is rechecked at execution. |
| Audit and revocation | Can an administrator review use and remove access without retaining provider responses? | Audit keeps operational metadata, while connections, grants, sessions, and API keys can be revoked. |
For a deployment-model decision, compare an MCP gateway with separate provider MCP servers. For a procurement review, use the 15-control MCP security checklist.
Which security features can customers operate?
Stackyapper gives workspace owners and administrators controls for access, higher-impact actions, security email, investigation, identity lifecycle, and revocation.
- App and tool permissions: grant access by group or person, narrow a broad app grant to individual tools, and use explicit restrictions that broader grants cannot override.
- Confirmation: require a short-lived, single-use confirmation bound to the exact proposed call for higher-impact operations when that policy applies.
- Alerts and summaries: send available security event types immediately or in a daily summary, and configure a weekly security summary with selected sections.
- Recipients: notify workspace owners and administrators and add verified shared destinations such as a security mailbox or PSA intake address.
- Location context: declare expected countries and choose full, truncated, or no client-address retention for later investigation. Immediate new-country and new-network alerts are not yet available.
- Audit and export: filter activity by workspace, date, service, result, and AI client, then export the narrowed record.
- Revocation: revoke clients, API keys, sessions, grants, connections, and memberships independently.
- Managed identity: Business workspaces can use managed SAML and Microsoft Entra SCIM for sign-in and user lifecycle management.
AI client admission controls
Release status: in production verification, not yet claimed as generally available.
The current release candidate adds an approved-clients-only policy, exact allow and block decisions for OAuth registrations and reviewed ChatGPT, Claude, and Hatz product profiles, and a separate policy for direct API-key clients. Existing workspace and tool permissions still apply after a client is admitted.
Direct API keys identify a member credential, not the software holding it. Stackyapper therefore keeps direct-key admission separate from verified OAuth client rules and requires an explicit warning before broad compatibility modes are enabled.
Does the AI client receive provider credentials?
No. Provider credentials are stored and resolved by Stackyapper for an authorized request. They are not returned to the AI client or embedded in the MCP tool result.
Can Stackyapper read the entire AI conversation?
Stackyapper receives the information the AI client includes in a tool request, not automatically the user’s full conversation. Routine logs record that a request occurred without storing its field values or the data returned by the connected app.
A specific workflow may intentionally persist an approved output or run record when the product clearly identifies that behavior. The public Privacy Policy and Data Processing Addendum describe the governing data practices.
What gets checked before a tool runs?
- The signed-in person or service identity.
- The selected internal or customer workspace.
- The connected provider and credential owner.
- The explicit service and tool grant.
- The type of action, such as read, write, delete, or credential-sensitive, and the policy for it.
- Exact-argument confirmation for actions that require it.
How does workspace isolation work?
Users, provider connections, MCP sessions, and audit records are resolved within one workspace. Administration of a parent organization does not automatically grant membership or MCP data access in another workspace.
This is what lets one company separate teams, and what lets a managed service provider separate each customer. Credential ownership stays attached to the correct user or organization scope, and every tool call is resolved again in the selected workspace.
Where it runs and how data is stored
Stackyapper runs entirely on Cloudflare. Cloudflare hosts the portal and MCP service, stores application data and private connector definitions, and holds temporary authorization state. There are no self-managed servers in the request path.
- Connector credentials are encrypted at rest with AES-256-GCM. Each record is sealed with a fresh 96-bit initialization vector and a 128-bit authentication tag using the Web Crypto API. The 256-bit key is held as a Worker secret, never in the database and never in source control.
- MCP API keys are stored as a hash, not as text. The database keeps a hash and a short display prefix so a key can be recognized and revoked, but the key itself cannot be read back out.
- Authorization state is short-lived. Temporary OAuth sign-in values expire automatically after 10 minutes.
- Outbound requests are restricted to public addresses. The Worker runs with Cloudflare’s strict public-fetch mode, so a connector cannot be pointed at internal or private network ranges.
- Encryption in transit and at rest for the underlying stores is provided by the Cloudflare platform.
- Connector definitions are private. They are not published at a public storage address and are accessible only to the Stackyapper service.
Where is data physically stored?
The primary database and object storage are located in Eastern North America (ENAM).
Requests are served from the Cloudflare edge location nearest the user, but stored data resides in the region above. If your organization has a residency requirement we do not currently meet, tell us before you connect anything.
Backup and recovery
The database supports point-in-time restore to any moment within the past 30 days.
Restores are performed by Stackyapper, not self-service, and overwrite the database at the chosen point. Because credentials are encrypted with a key held outside the database, a restore does not expose credential material.
What is kept, and for how long
| Data | Retention |
|---|---|
| Information returned from ordinary passthrough tool calls | Not stored. Provider responses stream through the request and are not written to a database or file system. A workflow may separately persist an approved output or run record when the product identifies that behavior. |
| Audit history available in the portal | Up to 90 days on Standard and 365 days on Business. Managed customer workspaces inherit the plan of the organization that manages them. Metadata only. |
| Portal sessions | 24 hours, then purged. |
| Authorization exchange state | 10 minutes. |
| Account and connection records | Until you delete them. Deleting a connection immediately removes or disables the active credential record; protected backup copies age out under the backup and legal-retention cycles described in the Privacy Policy and DPA. |
Who at Stackyapper can reach the platform?
Stackyapper's internal administrative tools require identity-provider authentication, and administrative actions are written to a separate platform audit log.
Administrative access to the hosting account is limited to named individuals with two-factor authentication required. There are no shared logins and no standing third-party access to production.
What does the audit history contain?
Operational audit records include metadata such as the actor, workspace, service, tool, result, duration, action type, client, and session identifiers.
Tool arguments are not written. Audit records keep field counts and sizes rather than field values. Failed calls use a standardized status instead of the provider's error text because those errors can repeat sensitive request values. Data returned by the connected app is not persisted.
What security email can a workspace configure?
Owners and administrators can choose immediate or daily delivery for event types currently marked available in the portal, keep a Monday security summary, and add verified shared recipients.
Available signals include managed identity changes, administrative role grants, destructive or credential-sensitive tool activity, repeated denied calls, and newly observed OAuth AI clients. Immediate new-country, new-network, connector credential-failure, and failed-sign-in-burst alerts remain unavailable until their producers are complete.
Expected countries add context to notifications but do not form a geographic access allowlist. Notifications report activity after it occurs. They do not replace identity, app, tool, risk, or confirmation checks.
What happens if there is a security incident?
If we confirm a security incident affecting your data, we will notify you without undue delay, and in any case within 72 hours of confirming it. Notification goes to the workspace’s administrative contacts by email.
We treat the following as reportable to you: unauthorized access to stored credentials or workspace data, unauthorized use of the MCP endpoint under your workspace, and any confirmed exposure of information covered by the Data Processing Addendum.
Our first notice will tell you what we know at the time rather than waiting for a complete picture: what happened, which of your workspaces and connected services are implicated, what we have done to contain it, and what we recommend you do. This will normally include rotating affected provider credentials and reviewing your audit history for the period. We will follow up as the investigation develops and provide a written summary once it closes.
We will not withhold notice because an investigation is incomplete, and we will not describe an incident as affecting you when it does not. If we are unsure whether your workspace is affected, we will tell you that.
Report a suspected vulnerability or incident to security@stackyapper.dev. We aim to acknowledge within one business day. If you are a security researcher acting in good faith, with no data exfiltration beyond what proves the finding, no service degradation, and no access to other customers’ data, we will not pursue legal action over your report.
Who is responsible for what
Stackyapper applies the safeguards described here to the gateway and the data it stores. You are responsible for the identities that reach it and the systems it connects to.
| Stackyapper | You |
|---|---|
| Encrypting and isolating stored credentials | Your identity provider, its configuration, and its recovery paths |
| Enforcing identity, workspace, tool, and risk checks on every call | Which users exist, which groups they belong to, and which tools you grant them |
| Keeping ordinary passthrough responses out of storage and standard logs, and identifying workflows that persist approved outputs or run records | Endpoints, authenticators, and AI-client configuration |
| Recording an audit trail and making it available to you | Reviewing that trail, and the scopes granted on the provider side |
| The availability and integrity of the gateway | Backups and recovery for your connected systems |
If your identity provider or a user account is compromised
A request that passes your identity provider and carries a valid grant is, to Stackyapper, a legitimate request. It will be authorized and served. Compromise of your identity provider, a user’s account, or an endpoint is not a breach of Stackyapper, and the Data Processing Addendum places investigation and any required notifications with you in that case.
That is the contractual line, but it is not where our involvement ends. Two things follow from it:
- You can investigate the activity. Audit records and the notification types currently marked available in the portal can help administrators identify unexpected access. Notification settings report activity; they do not block it.
- We will help you reconstruct it. Audit history records the actor, workspace, service, tool, result, and client. Network context is included when the workspace retains it. This is usually the fastest way to establish what an attacker actually reached, and we will provide available records on request during an investigation.
What limits the damage in this scenario is the access you granted in advance. A compromised account can only do what that account was permitted to do. This is the practical argument for granting individual tools rather than whole services and requiring confirmation for higher-impact actions where that safeguard applies.
Certification status
Stackyapper does not hold a third-party security certification today. The controls described on this page are implemented and documented; they have not been audited by an outside firm, and this page is not a certification or warranty.
We would rather state that plainly than imply coverage we cannot evidence. Certifications held by our infrastructure providers apply to that infrastructure, not to Stackyapper itself. If your review needs specific answers about architecture, data handling, subprocessors, or a completed questionnaire, write to security@stackyapper.dev and we will answer directly.
MCP access control questions
Does MCP authentication control which tools a user can run?
Not by itself. Authentication establishes who reached the MCP server. The server still needs authorization that checks the workspace, connected service, tool grant, action risk, and any required confirmation when the tool is called.
Can an MCP gateway prevent every unsafe AI action?
No. A gateway can reduce access and credential risk, but it cannot make every instruction or provider action safe. Administrators still own identity security, provider scopes, tool grants, workflow design, and human oversight.
Standards and security references
- Model Context Protocol authorization specification
- Model Context Protocol security best practices
- OWASP MCP Security Cheat Sheet
Security and legal resources
Report suspected vulnerabilities to security@stackyapper.dev.
For formal security or procurement questions, contact security@stackyapper.dev.