Give AI useful access without handing it the keys.

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 MCP request the AI client sends, not the user’s full conversation. Standard operational logs record call metadata rather than provider response bodies.

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 tool’s risk class and current policy.
• 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. The MCP endpoint and portal are Cloudflare Workers; application data is in Cloudflare D1; short-lived authorization state is in Workers KV; connector artifacts are in R2. 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. OAuth exchange material in Workers KV carries a 10-minute expiry and is discarded automatically.
• 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.
• Object storage is private. The connector artifact bucket has no public development URL and no custom domain; it is reachable only by the Worker through its binding.

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

Who at Stackyapper can reach the platform?

Administrative tooling sits behind Cloudflare Access. Reaching the control plane requires passing identity-provider authentication at the edge before any application code runs, and platform 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, risk class, client, and session identifiers.

Tool arguments are not written. The audit record stores the shape of a call — argument count and byte sizes — rather than its content, and a failed call records a fixed status string instead of the provider’s error text, because provider errors frequently echo request values back. Provider response bodies are never persisted.

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 — normally rotating the 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 — no data exfiltration beyond what proves the finding, no service degradation, no access to other customers’ data — we will not pursue legal action over your report.

Who is responsible for what

Stackyapper secures the gateway and everything stored inside it. You secure the identities that reach it and the systems it connects to.

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:

• We will still tell you. If we detect activity that looks like compromised access — an established user appearing from an unfamiliar network, a burst of denied calls, a first-time destructive action — we will raise it with you promptly, without waiting to establish whose fault it is.
• We will help you reconstruct it. The audit history records the actor, workspace, service, tool, result, client, and originating network for every call. That is usually the fastest way to establish what an attacker actually reached, and we will provide it 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, which is the practical argument for granting individual tools rather than whole services, and for keeping confirmation on destructive actions.

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 — architecture, data handling, sub-processors, or a completed questionnaire — write to security@stackyapper.dev and we will answer directly.

Security and legal resources

• Trust center
• Privacy Policy
• Data Processing Addendum
• Subprocessors
• Acceptable Use Policy

Report suspected vulnerabilities to security@stackyapper.dev.

Architecture summary reviewed July 24, 2026. It is explanatory product documentation, not a certification or warranty.