security &trust.
Our SOC 2 Type II audit is officially underway — we’re in the mandatory observation window with the final report expected November 2026. This page is written so your security team can complete a vendor review from it alone; the Trust Center handles the paperwork.
Due diligence, without the email chain.
Everything procurement asks for lives at trust.stackjack.io — stop emailing spreadsheets back and forth.
The StackJack Trust Center
One portal for your entire vendor review — self-serve where possible, human where it matters.
- Submit your DDQ, SIG, SIG-Lite, or CAIQ — upload the questionnaire and we complete it against our documented controls.
- Request policies & documents — security policies, DPA, certificates of insurance, architecture overview, and audit artifacts under NDA where required.
- Track our SOC 2 Type II audit live — real-time control status through the observation window to the final report.
- Sub-processor & incident notices — subscribe to change notifications so your vendor register stays current.
- Readiness & controls implementedComplete — controls documented and operating.
- Mandatory observation windowUnderway now — auditor observing controls in operation.
- Final Type II reportExpected November 2026 — available under NDA via the Trust Center.
We claim no certification we don’t hold: no ISO 27001, HIPAA BAA, PCI DSS, or FedRAMP. Azure’s underlying certifications apply to inherited infrastructure only.
Security at a glance.
The essential security facts about StackJack — in 30 seconds.
Zero retention on the gateway
The MCP gateway is pass-through: your PSA/RMM data is never stored, cached, or logged — only audit metadata. In fact, nothing StackJack stores contains customer data beyond metadata — details in the data inventory.
Credentials in Azure Key Vault
Every connector secret lives exclusively in Azure Key Vault — software-protected, encrypted at rest with FIPS 140-2 validated cryptography. Our database holds only a reference, never the secret.
Fail-closed authentication
Every request passes a multi-layer pipeline — OAuth 2.0 with mandatory PKCE or BCrypt-verified Basic auth. Any validation failure means denial. No exceptions, no fallbacks.
Tenant isolation
Data, credentials, rate limits, and access controls are isolated per tenant at the database, Key Vault, cache, and rate-limit layers. No cross-tenant queries exist anywhere in the system.
SOC 2 Type II in progress
Officially in the mandatory observation window; final report expected November 2026. Track status, request documents, and submit DDQs at the Trust Center.
AI under your control
Agents — interactive or autonomous — run inside per-agent tool allowlists, plan gating, and usage caps, with every call audited. Bring your own Anthropic key (BYOK) to keep AI billing and control on your account.
The StackJack security model.
A detailed look at how every layer of StackJack is designed to protect your data and access — across 71+ integrations spanning PSA, RMM, security, identity, and billing tooling.
Pass-Through Gateway Architecture
The MCP gateway is a stateless proxy. Your connector data flows through, never stops.
How it works
Your AI agent sends a tool call to StackJack. We authenticate the request, resolve your tenant, and forward the API call to your connector — HaloPSA, ConnectWise, NinjaRMM, CIPP, and 30+ more. The response streams back to your agent and is discarded from memory after transit.
What we retain
Audit metadata only: which tool was called, by which tenant, client, and user, whether it succeeded, and how long it took. Request parameters and response content are never logged on the gateway path.
Transcripts & Support-AI
Agent run transcripts can contain connector data — which is exactly why they live on your AI provider’s infrastructure (Microsoft Foundry or Anthropic), not ours: StackJack streams one on demand when you click to view a run and never persists it. Support-AI processes support-ticket content you send us. Both flows are disclosed in the data inventory.
Credential Management
Every secret is encrypted, hashed, or stored in a dedicated secrets vault. Zero plaintext, anywhere.
Azure Key Vault
All connector secrets — client secrets, refresh tokens, API keys — live in Azure Key Vault (Standard tier, software-protected), encrypted at rest with FIPS 140-2 validated cryptographic modules. The database stores only a reference name.
MCP client secrets
When you create an MCP client, a cryptographically random 256-bit secret is generated and shown to you exactly once. We store only an irreversible BCrypt hash. We cannot recover your secret — by design.
Zero plaintext policy
No plaintext secrets in the database, cache, or logs. Connector credentials live in Key Vault; client secrets are BCrypt hashed; OAuth signing keys are in Key Vault. The application reaches Key Vault via managed identity — no human holds standing credentials.
Authentication: Two Distinct Lanes
How your AI reaches StackJack, and how StackJack reaches your connectors, are separate systems — each secured for what it is.
Lane 1: your AI → StackJack
OAuth 2.0 with mandatory PKCE, RSA-signed JWT access tokens with short expiry, and single-use rotating refresh tokens — or HTTP Basic with BCrypt-verified secrets. Every request is independently authenticated.
Lane 2: StackJack → your connectors
Connector authentication varies per vendor — OAuth client-credentials, rotating refresh tokens, static API keys, self-signed JWTs. Whatever the vendor requires, the secret is stored in Azure Key Vault, never in the database, and is scoped to your tenant.
Fail-closed design
Denied: invalid or expired JWT. Tenant not found. Subscription inactive. Credentials unloadable from Key Vault. Tool not in the allowlist. Usage cap exceeded. Any check that cannot positively pass means the request never reaches your connector.
Tenant Isolation
Your data is architecturally unreachable by any other tenant.
Database isolation
Every query includes your tenant ID in the WHERE clause. No admin endpoints query across tenants; no reports aggregate cross-tenant data. Cross-tenant access paths don’t exist in the code.
Credential isolation
Each tenant’s connector secrets are separate Key Vault entries scoped by tenant identity — and optionally per user. Credential lookup is bound to the authenticated tenant established during authentication.
Cache & rate limit isolation
All cached data is keyed by tenant ID. Rate limits are tracked independently per tenant per connector. One tenant hitting a limit has zero effect on any other — the noisy-neighbor problem is eliminated by design.
Rate Limiting & Abuse Prevention
Multiple layers of protection for your connector APIs and every other tenant on the platform.
Multi-layer rate limiting
Per-tenant burst limits (per-minute), per-connector monthly usage caps by plan, and upstream API protection calibrated to each vendor’s published thresholds — three independent layers.
Upstream API protection
StackJack tracks request rates per connector and stays within each vendor’s limits. If an upstream API rate-limits us, StackJack backs off automatically — your PSA/RMM instance is never hammered.
Structured error responses
When a limit is hit, agents receive structured JSON with the exact limit, current usage, and a Retry-After interval — designed for machine consumption so agents back off intelligently instead of retrying blindly.
Transport Security
Every connection is encrypted. There is no unencrypted path through StackJack.
HTTPS everywhere
All production traffic flows over HTTPS with TLS termination at the Azure edge. Database connections require TLS 1.2+. Redis is SSL-only with the non-SSL port disabled.
Streamable HTTP transport
Pure HTTP request/response over HTTPS. No persistent connections, no WebSocket upgrade paths, no long-lived sessions — every request is independently authenticated.
Resilience patterns
All upstream calls include automatic retry with exponential backoff, circuit breakers, and configurable timeouts. When a connector API struggles, StackJack degrades gracefully instead of cascading failures.
The honest data inventory.
Here is exactly what exists on our infrastructure — and what deliberately doesn’t. The rule is simple: nothing StackJack stores contains customer data beyond metadata.
Never persisted — gateway lane
Tickets, clients, devices, contacts, invoices, assets — anything returned by your connectors during interactive MCP tool calls. No caching, no indexing, no logging of parameters or response bodies. It transits memory and is discarded.
Stored to run the service
Tenant name and email, Zitadel user IDs, a Paddle customer reference (Paddle is our Merchant of Record — card data never touches StackJack), team member emails, connector instance URLs, usage audit logs (tool, status, duration, truncated error on failure), and support tickets.
Agent run transcripts — not stored here
Automations transcripts can contain connector data returned during a run, so StackJack never stores them. They rest on your AI provider’s infrastructure, nothing is loaded by default, and when you click to view a run the transcript is streamed from Anthropic on demand for display. StackJack keeps only per-run metadata: agent, tools called, status, duration.
Support-AI ticket processing
When you open a support ticket, Support-AI correlates internal signals (codebase, Sentry, Azure telemetry, known issues) to draft a reply for human approval. Vectors in Azure AI Search are PII-redacted, and all Support-AI data is purged when the ticket closes. Full pipeline in the AI section.
Observability — stated plainly
Our stack is OpenTelemetry (traces, metrics, logs) plus Sentry for errors. Sentry events include tenant ID, user ID, connector type, and plan, and we intentionally retain diagnostic detail to run the service. It is access-controlled, retention-bound, and never sold or shared. We won’t claim “zero PII in error tracking” — that claim is rarely true for anyone.
Deletion & retention
Account deletion cascade-deletes database records, purges Key Vault secrets, and lets tenant-keyed cache entries expire within minutes. Usage logs and Automations run metadata live on defined retention windows and die with the account; Support-AI data purges when its ticket closes.
AI agents, on a leash you hold.
Automations run AI agents on manual, scheduled, and webhook triggers. Autonomy changes nothing about authority: agents get the same fail-closed controls as humans — and less trust, not more.
Same controls as interactive use
Per-agent tool allowlists, plan gating, and usage caps. An agent can’t call a tool outside its allowlist, discover hidden tools, or escalate its own permissions — enforcement doesn’t care that the caller is autonomous.
Audited and budget-capped
Every agent tool call is logged — tool, status, duration, tenant, agent, user — and runs execute in isolation under per-run credit and budget caps. No unbounded fan-out, no surprise invoice.
Webhook triggers hardened
Inbound payloads are authenticated before they trigger anything, and content is treated as untrusted data, never instructions — a webhook can start an agent, not reprogram one.
Bring your own key (BYOK)
Supply your own Anthropic API key and Automations plus Support-AI run on your AI account and billing — direct provider relationship, spend control, revocation at the source.
Destructive-action controls
All four liveWrite access is never implicit — four independent gates sit between an autonomous agent and a destructive action.
Destructive tools stay off the agent’s allowlist unless you explicitly include them.
Per-agent opt-in required before any autonomous destructive or write action.
Read-only tool filtering, with an operator approving individual actions live before promotion.
Each agent runs under its own scoped identity, and agent configuration itself is role-gated.
Support-AI: signal correlation, not data mining
Support-AI exists to answer your ticket faster by correlating our own signals automatically — the codebase for bug-fix potential, Sentry error logs, Azure telemetry, and known issues in harness metadata — and matching them to knowledge-base articles and a drafted response that a human must approve before it reaches you. Ticket text is embedded via Voyage AI and indexed in Azure AI Search with PII redaction enabled, so no PII is stored in the vector index — and all Support-AI data for a ticket is purged when the ticket closes. Anthropic drafts under commercial terms that prohibit training on your data.
Who touches what, and why.
The complete sub-processor list your DDQ asks for. We notify customers via the Trust Center before a new sub-processor processes customer data.
| Sub-processor | Purpose | Data categories | US region | EU region | APAC region |
|---|---|---|---|---|---|
| Microsoft Azure | Hosting — SQL database, Key Vault, Blob storage, Container Apps, AI Search, Log Analytics | Account data, secrets (Key Vault), audit metadata, Automations run metadata (no transcripts) | Central US, East US & West US 2 | Sweden Central | Coming soon |
| AI inference — configurable per tenant: Microsoft Foundry (default on EU) or Anthropic | AI inference for Automations and Support-AI; run transcripts rest with the inference provider — streamed to StackJack on demand for display, never persisted by StackJack | Tool/prompt context and run transcripts for agent runs; support-ticket evidence. No training on customer data (commercial terms) | Foundry: East US / West US 2, or Anthropic (global, US-lockable) | Foundry: Sweden Central | Coming soon |
| Zitadel | Identity provider / SSO (OIDC) | Authentication identifiers | US | EU | Coming soon |
| Paddle | Payments — Merchant of Record; handles all card data and PCI DSS scope | Billing identifiers only — StackJack stores no card or payment-instrument data | Global (UK HQ) — not tenant data | ||
| WordPress (stackjack.io) | Marketing site & signup routing | Contact and signup identifiers | US — pre-signup contact data only, not tenant data | ||
| SendGrid | Transactional email | Recipient email and name | US — recipient email/name only | ||
| Embeddings — configurable per tenant: Microsoft Foundry (default on EU) or Voyage AI | Support-ticket text embeddings (Support-AI vector search) | Support-ticket content — vectors PII-redacted, purged when the ticket closes | Foundry: East US / West US 2, or Voyage AI (US) | Foundry: Sweden Central | Coming soon |
| Sentry | Error monitoring | Application errors with tenant/user identifiers and diagnostic context | US — diagnostic context only | ||
Everything that holds PII or tenant-attributable data — hosting, identity, AI inference, embeddings — is residency-compliant in your chosen region. On the EU instance, AI defaults to Microsoft Foundry in Sweden Central; tenants may instead configure Anthropic (processes globally, can be locked to US) for Automations and Support-AI. Paddle, WordPress, SendGrid, and Sentry handle billing, pre-signup, email, and diagnostic metadata only — never connector or tenant operational data.
Regions reflect primary processing locations; the authoritative, current list — with change notifications you can subscribe to — is maintained in the Trust Center.
Privacy posture, in writing.
Our role
Processor for connector operations and data transiting the gateway on your instructions; controller for your account data (name, email, billing linkage). Scope and instructions are set out in our DPA.
GDPR / UK GDPR
A DPA meeting Art. 28 requirements is available via the Trust Center; technical and organisational measures per Art. 32 are the controls on this page. International transfers rely on Standard Contractual Clauses (and the UK Addendum) where applicable.
CCPA / CPRA
We do not sell personal information and we do not share it for cross-context behavioral advertising. Revenue is subscriptions — your data is not the product.
Data-subject & deletion requests
Send requests to security@stackjack.io or raise them in the Portal. Verified requests are actioned without undue delay — target 30 days — via cascade deletion, Key Vault purge, and cache expiry.
Data residency
Two regions: US (Azure Central US, East US, and West US 2) and EU (Azure Sweden Central) — APAC coming soon. You choose your data residency region at checkout, and everything holding PII or attributable data — database, secrets, identity (Zitadel), AI inference and embeddings (Microsoft Foundry) — stays in that region. Customer data is not replicated outside Azure. For EU tenants that means GDPR-aligned, in-region processing on EU soil — no US transfer required for tenant data.
Sub-processor notice
Additions and changes are published to the Trust Center with advance notice before a new sub-processor handles customer data, so your vendor register never goes stale silently.
How the software gets built.
Code review — including adversarial
Changes are reviewed before merge, including adversarial AI-assisted review that hunts for injection paths, authorization gaps, and tenant-isolation regressions — not just style nits.
Build & test gates
Every deploy passes build and automated test gates before it ships; rollouts are health-gated rolling revisions with automatic rollback on probe failure. Zero-downtime by default.
Dependencies & patching
Dependencies are updated on a continuous cadence; the platform layer (OS, runtime, TLS termination) is patched by Azure as managed infrastructure.
No secrets in source
Secrets are never committed to source control. The application authenticates to Azure services via least-privilege managed identities — there are no connection passwords to leak.
Penetration testing
Formal third-party penetration testing is part of the SOC 2 program now underway; summaries will be available under NDA through the Trust Center.
Responsible disclosure
Found something? Email security@stackjack.io (fallback: ceej@stackjack.io). We commit to good-faith safe harbor: security research conducted in good faith — no data exfiltration, no service disruption, prompt reporting — will not be met with legal action.
When something breaks, you hear it from us.
Detection & monitoring
Sentry error monitoring plus OpenTelemetry traces, metrics, and logs across every replica — alerting on error rates, auth-pipeline anomalies, and availability, not just uptime pings.
Response process
Assess and contain; identify affected tenants and data; notify; remediate; publish a post-incident report. Tenant isolation and Key Vault custody bound the blast radius while we work.
Breach notification commitment
If an incident affects your data, we notify you without undue delay after confirmation — by email to your account address and via the Trust Center — with what happened, what was affected, what to do, and what we’re changing. You hear it from us first, not from a news article.
Built to stay up — and boring to recover.
Backups & point-in-time restore
Azure SQL automated backups with point-in-time restore across a 35-day window. Restore points land within minutes of live; formal RTO/RPO targets are being finalized in SOC 2 documentation and are available via the Trust Center.
Health-gated auto-scaling
Azure Container Apps with startup, readiness, and liveness probes plus automatic horizontal scaling. Deploys are rolling revisions — traffic only reaches verified-healthy replicas.
Regional posture
Production runs in two regions — US (Azure Central US, East US, and West US 2) and EU (Azure Sweden Central), chosen per tenant. And because the gateway is stateless, an outage means paused tool calls — never lost data: your PSA/RMM keeps running untouched.
Every control, in one table.
Live means running in production today — and today that’s everything here except the third-party pen test (part of the SOC 2 program).
MCP security: myths vs. reality.
We keep seeing the same claims about MCP security. Here’s what’s actually true.
MCP is a protocol, not a product — security is in the implementation.
Most MCP criticism targets the local stdio transport: credentials in plaintext JSON config files, no authentication, any local process able to connect. That concern is fair — for that configuration.
StackJack is remote authenticated MCP over HTTPS: multi-layer authentication, credentials in Azure Key Vault, fail-closed access, encrypted transport. Same protocol, entirely different security posture — like SQLite on a desktop versus a production database with encryption, RBAC, and TLS.
True for stdio. StackJack implements the full MCP OAuth spec — and more.
The harness lane uses OAuth 2.0 with mandatory PKCE (S256 only), RSA-signed JWT access tokens with short expiry, and single-use rotating refresh tokens; HTTP Basic with BCrypt-hashed secrets is also supported. Dynamic Client Registration is rate-limited against automated abuse.
Even a valid token isn’t enough: you must be the tenant owner or an active member. Membership is checked on every request — removal is instant revocation.
StackJack agents get exactly the tools you allowlist — nothing more.
Per-client and per-user allowlists operate fail-closed: if a tool isn’t on the list it can’t be called, and the check runs in the execution pipeline before any API call is forwarded. Plan gating adds a second gate; bulk operations are capped and inputs validated.
Only if you hand it delete tools. You decide the boundary between observation and action.
Most StackJack tools are read-only; write and destructive tools require explicit enablement in your configuration. Bulk operations are capped per call, inputs are validated, and every call is audited with tenant, client, user, tool, and status. The AI cannot force its way past controls it never receives — and autonomous agents face four additional destructive-action controls: explicit acknowledgment, supervised dry-run, scoped credentials, and config RBAC.
The gateway is pass-through — and nothing at rest here contains customer data.
On the MCP gateway path your data transits memory and is discarded; we log tool name, status, and duration — never parameters or response bodies. There is no query an employee could run that returns your tickets or devices, because that data doesn’t persist here.
Agent run transcripts can contain connector data, so they don’t live here at all — they rest on your AI provider’s infrastructure (Microsoft Foundry or Anthropic) and are streamed on demand only when you click to view a run. Support-AI ticket processing is spelled out in the data inventory. What StackJack itself stores never goes beyond metadata.
Defense in depth: every layer limits the blast radius of the next.
Full database access yields zero usable connector credentials — only Key Vault references. Client secrets are irreversible BCrypt hashes. Tokens expire in hours; refresh tokens are single-use, so a stolen one works at most once and its reuse is a detection signal. Tenants are isolated at every layer, and Key Vault soft delete plus purge protection make even malicious deletion recoverable. Rotation and revocation are instant from the Portal.
Good. You should be. That instinct is why this page is this long.
StackJack was built security-first by engineers who’ve shipped SOC 2 Type II audited products on this same stack — and StackJack itself is now officially in its SOC 2 Type II observation window, with the final report expected November 2026. This page shows the architecture instead of asking for trust; the Trust Center carries the evidence. If something you need isn’t covered, ask: security@stackjack.io.
Every DDQ answer, already visible.
No accordions to dig through — every answer is on the page, grouped by assessment domain, filterable, and Ctrl-F-able. Need it in your questionnaire format? Upload the DDQ to the Trust Center and we’ll complete it.
[ 01 · data handling & retention ]
Does StackJack store my PSA/RMM data?
No. Interactive MCP tool calls are pass-through: data transits memory and is discarded; we log tool name, status, and duration — never parameters or response bodies.
Nothing StackJack stores contains customer data beyond metadata. Agent run transcripts rest on Anthropic’s infrastructure — streamed on demand when you view a run, never stored by StackJack — and Support-AI processes support-ticket content. See the data inventory.
What data do you store to operate the service?
Tenant name and email, Zitadel user IDs, a Paddle customer reference, team member emails and display names, connector instance URLs, usage audit logs (tool, status, duration, truncated error on failure), Automations run metadata (transcripts stay on Anthropic’s infrastructure), and support tickets. Credentials live only in Azure Key Vault as references.
Do you log tool call parameters or API responses?
No — deliberately, so customer operational data cannot exist in our logs regardless of which tools run. Full agent run transcripts exist only on Anthropic’s infrastructure and are streamed on demand when you open a run — StackJack never stores them.
How is data classified and handled?
Three classes: connector data (most sensitive — never persisted on the gateway), secrets (Key Vault only, zero plaintext), and account/audit data (SQL with TDE, tenant-scoped). Handling rules follow the class, not convenience.
What are your retention windows?
Cache entries expire on TTLs from minutes to days. Usage logs and Automations run metadata are kept on defined retention windows to power your dashboard and audit trail. Account data persists until you request deletion. Current windows are documented in the Trust Center.
How does secure deletion work?
Account deletion cascade-deletes all database records, purges tenant secrets from Key Vault, and tenant-keyed cache entries expire within minutes. Requests via the Portal or security@stackjack.io; verified requests actioned without undue delay (target 30 days).
Where does my data physically live?
Microsoft Azure, in the region you choose at checkout — US (Central US, East US, and West US 2) or EU (Sweden Central): SQL (TDE) for account and audit data, Key Vault for secrets, Redis for tenant-keyed cache, Blob for support attachments, AI Search for PII-redacted Support-AI vectors (purged on ticket close). Identity (Zitadel) and AI inference/embeddings (Microsoft Foundry) are also region-pinned. No replication outside Azure or outside your chosen region.
Can EU tenant data stay in the EU?
Yes. Pick the EU region at checkout and your tenant is provisioned in Azure Sweden Central: database, Key Vault, cache, blob, vectors, identity (Zitadel EU), and AI inference/embeddings (Microsoft Foundry, Sweden Central). No cross-region replication, no US transfer of tenant data.
Are you GDPR compliant? Do you offer a DPA with SCCs?
EU tenants get in-region processing by default, a deletion cascade, defined retention windows, and PII redaction on Support-AI vectors. A DPA including Standard Contractual Clauses (for the residual US-only services: email delivery, error diagnostics, billing) is available via the Trust Center.
Can I move regions later?
Existing customers can migrate self-service from the portal; new tenants pick a region at signup/checkout. Migration moves your tenant’s stored data; connector credentials re-encrypt into the destination region’s Key Vault.
Do you sell, share, or train on my data?
No. No sale, no sharing, no advertising, no data brokers. We don’t train models on customer data, and our AI sub-processors (Anthropic, Voyage AI) operate under commercial terms that prohibit training on it. Revenue is subscriptions only.
[ 02 · credentials & key management ]
Where are my connector credentials stored?
Exclusively in Azure Key Vault; the database stores only a reference name. Credentials are cached briefly in Redis (tenant-keyed) and the cache is evicted immediately on rotation.
Is Key Vault HSM-backed?
We use Key Vault Standard tier — software-protected, not the HSM-backed Premium tier. Secrets are still encrypted at rest with FIPS 140-2 validated cryptographic modules, with RBAC authorization, soft delete, and purge protection. We say this plainly because your DDQ will ask.
Can StackJack employees access my credentials?
No standing access exists. Key Vault is reached by the application’s managed identity — a platform-issued cryptographic identity, not a password anyone holds. The database contains only references; production access is least-privilege and audited.
How are MCP client secrets handled?
Generated as 256-bit cryptographically random values, shown exactly once, stored only as irreversible BCrypt hashes with constant-time comparison. Lost secrets are rotated, never recovered — by design.
How does StackJack authenticate to my connectors?
Per vendor: OAuth client-credentials, rotating refresh tokens, static API keys, or self-signed JWTs — whatever each platform requires. Every variant is stored in Key Vault, never the database. (Single-use rotating refresh tokens are a property of the harness→StackJack lane and some connectors, not a blanket claim.)
Can I rotate credentials, and how fast does it apply?
Instantly, via the Portal: new values write to Key Vault, the cache is evicted, and old Key Vault versions soft-delete. MCP client rotation invalidates the old secret on the next request. Rotate on schedule and after any suspected compromise.
Who holds the JWT signing keys?
RSA signing keys live in Azure Key Vault, loaded by managed identity and consistent across replicas; the public key is published via a standard JWKS endpoint for verification.
Shared vs per-user connector credentials?
Free/Pro tenants share one credential set per connector; per-user credentials give each team member their own Key Vault-scoped secrets, so upstream PSA/RMM audit logs attribute actions to the individual, not a service account.
[ 03 · authentication & sessions ]
How do AI agents authenticate to StackJack?
OAuth 2.0 with mandatory PKCE (S256 only) issuing RSA-signed JWTs, or HTTP Basic verified against BCrypt hashes. Every request passes identity → authorization → rate-limit layers; any failure is denial.
Do you support MFA?
Yes — MFA is available through Zitadel, our identity provider (region-pinned: US or EU with your tenant), and enforced for Portal access. AI-agent connections authenticate with cryptographic credentials (tokens/secrets) rather than passwords.
Do you support SSO?
The Portal uses OpenID Connect (authorization code + PKCE) via Zitadel. Per-user MCP access rides the same OIDC identity, so each tool call can carry a human identity.
How are Portal sessions secured?
HttpOnly, Secure, SameSite cookies; limited lifetimes with background token refresh; failed refresh invalidates the session immediately. StackJack never sees your Zitadel password.
What are your token lifetimes?
Access tokens live hours, not days. Refresh tokens are single-use and rotate atomically on every use — a stolen refresh token works at most once, and its reuse is a detection signal.
Can credentials be brute-forced?
Practically no: 256-bit random secrets (2256 search space), deliberately expensive BCrypt verification, and burst rate limiting that trips long before meaningful progress.
[ 04 · access control & rbac ]
What roles exist?
Owner (everything incl. billing), Admin (team, credentials, MCP clients — no billing), Member (tool use within their allowlist). Enforced at both the Portal and the MCP execution layer. Agent-runner configuration is also role-gated — you control who may create or modify autonomous agents.
Can I restrict which tools an AI or user can call?
Yes — per-client and per-user allowlists, fail-closed: configured-but-empty means zero tools, malformed means deny-all, and the check runs before any connector call. Changes apply immediately.
Can I separate read-only from write/destructive access?
Yes. Most tools are read-only; write and destructive tools must be explicitly included. Common pattern: read-only clients for exploration, a tightly-scoped write client for production automations.
How fast is access revocation?
Instant — membership is verified on every MCP request, so removing a member kills even technically-valid tokens on their next call. No cache windows, no grace periods.
How is least privilege applied internally?
The application reaches Azure services through least-privilege managed identities; Key Vault uses RBAC; there is no standing plaintext-credential access for humans, and production access is audited.
What does the enforcement pipeline look like?
Sequential and unskippable: tool-allowlist check → plan gating → usage caps → execute → audit log. A failure at any step returns a structured error and the connector is never contacted.
[ 05 · ai, agents & model providers ]
Which AI providers process customer data?
Configurable per tenant. Inference for Automations and Support-AI runs on Microsoft Foundry (region-pinned; Sweden Central on the EU instance, the default there) or Anthropic (processes globally, can be locked to US). Embeddings likewise: Foundry (region-pinned) or Voyage AI (US). All under commercial terms prohibiting training on customer data. Your interactive AI conversations happen between your AI client and its provider — StackJack only sees the tool calls.
Can AI processing be kept in the EU?
Yes. On the EU instance, Automations and Support-AI default to Microsoft Foundry in Sweden Central — inference and embeddings never leave the region. Anthropic is an opt-in alternative (processes globally, can be locked to US regions); Voyage embeddings are US. The choice is per tenant, in the portal.
Do you support BYOK (bring your own key)?
Yes. Supply your own Anthropic API key and Automations plus Support-AI run on your account and billing — you keep direct control of the provider relationship, spend, and revocation. The key is stored in Key Vault like any other secret.
Can an autonomous agent exceed its permissions?
No. Agents are constrained by the same fail-closed controls as interactive use: per-agent allowlists, plan gating, tenant caps. They cannot discover hidden tools, call outside the allowlist, or escalate their own permissions.
Are agent actions audited?
Every agent tool call is logged with tool, status, duration, tenant, agent, and user. The full run transcript is viewable on demand — streamed from Anthropic’s infrastructure when you open the run; StackJack never stores it.
What bounds an agent run’s blast radius and cost?
Execution isolation and per-run credit/budget caps — runs cannot fan out unboundedly, and spend is capped before the run starts.
What controls exist for destructive agent actions?
Destructive tools stay off the agent’s allowlist unless you opt them in, with bulk caps and full audit. On top of that — all live: per-agent destructive-action acknowledgment before autonomous write actions, supervised dry-run mode (read-only filtering with live operator approval of individual actions), and per-agent credential binding to scoped identities.
How are webhook triggers secured?
Inbound payloads are authenticated before triggering anything, and payload content is treated as untrusted data — it can start a run, never inject instructions into one.
How does Support-AI process my tickets?
By correlating signals, not mining your data: it checks our codebase for bug-fix potential, Sentry logs, Azure telemetry, and known harness issues, matches them to KB articles, and Anthropic drafts a reply a human must approve. Ticket vectors in Azure AI Search are PII-redacted, and all Support-AI data is purged when the ticket closes.
[ 06 · multi-tenancy & isolation ]
Can another tenant reach my data or credentials?
No. Tenant ID scopes every database query, every Key Vault secret, every cache key, and every rate-limit counter. Isolation is structural — cross-tenant code paths don’t exist.
What if there’s a bug in one isolation layer?
Defense in depth: database, Key Vault, cache, and rate-limit isolation operate independently. A defect in one cannot leak Key Vault secrets or cross-contaminate tenant-keyed caches — multiple independent systems would have to fail simultaneously.
Is StackJack single-tenant or multi-tenant?
Multi-tenant with logical isolation at every layer, as described above. Dedicated single-tenant deployments aren’t currently offered — if you have a hard requirement, raise it via the Trust Center.
How do you prevent noisy neighbors?
Per-tenant burst and monthly limits, per-tenant upstream API protection, stateless replicas that scale horizontally under load, and zero shared state between tenants.
[ 07 · infrastructure & network ]
Where is StackJack hosted?
Entirely on Microsoft Azure (Central US, East US, West US 2): Container Apps, Azure SQL, Key Vault, Redis, Blob Storage, AI Search, Container Registry. No non-Azure services sit in the data path.
Is data encrypted in transit?
Yes — TLS 1.2+ on every hop: client→StackJack, StackJack→connectors, and all internal service connections. Redis is SSL-only with the non-SSL port disabled; TLS 1.0/1.1 are unsupported everywhere.
Is data encrypted at rest?
Yes — Azure SQL TDE (AES-256) including logs and backups, Key Vault FIPS-validated encryption for secrets, platform encryption for Redis and Blob. BCrypt-hashed client secrets are stronger than encrypted — there’s no key to steal.
How is the network segmented?
HTTPS-only ingress at the Azure edge; data services accept only encrypted connections from the application, which authenticates via managed identity. There are no VPN paths or agents installed in your environment — StackJack only makes outbound HTTPS calls to your connectors’ APIs.
What about physical security?
Inherited from Microsoft Azure data centers and their certifications (ISO 27001, SOC, FedRAMP) — referenced as inherited infrastructure only, not claimed as StackJack’s own.
How are changes deployed?
Health-gated rolling revisions: new replicas take traffic only after startup and readiness probes pass live database/Redis checks; failures roll back automatically. Zero-downtime, no maintenance windows.
[ 08 · application security & sdlc ]
What does your secure SDLC look like?
Reviewed changes (including adversarial AI-assisted review targeting injection, authz gaps, and isolation regressions), build+test gates before deploy, secrets never in source, least-privilege managed identities throughout.
How do you manage vulnerabilities and patching?
Continuous dependency updates at the application layer; Azure patches the managed platform beneath (OS, runtime, TLS termination). Input validation clamps page sizes, validates enums/dates/IDs, and rejects malformed JSON before anything reaches your connector.
Have you had a third-party penetration test?
Formal third-party testing is scheduled within the SOC 2 program currently underway; result summaries will be available under NDA via the Trust Center. We’d rather tell you that than point at a stale report.
Do you have a responsible disclosure policy?
Yes: report to security@stackjack.io (fallback ceej@stackjack.io). Good-faith research — no exfiltration, no disruption, prompt reporting — gets safe harbor, not lawyers.
How do you defend against DDoS and abuse?
Azure edge protections plus StackJack’s own multi-layer rate limiting (per-tenant burst, monthly caps, DCR registration throttling) — abuse is throttled before it reaches anything expensive.
How do you prevent prompt injection from reaching my systems?
The enforcement pipeline doesn’t trust the AI: allowlists, plan gates, caps, and input validation run server-side against stored configuration, not against anything the model says. Webhook payloads are likewise data, never instructions.
[ 09 · logging, monitoring & incident response ]
What is your observability stack?
OpenTelemetry (OTLP traces, metrics, logs) plus Sentry for error monitoring.
Does your error tracking contain personal data?
Honestly: yes, some. Sentry events carry tenant ID, authenticated user ID, connector type, and plan, plus diagnostic detail we intentionally retain to troubleshoot. It’s access-controlled, retained for a defined period, and never sold or shared. We do not claim “zero PII in error tracking.”
What audit trail do customers get?
Every tool call — interactive or agent — with timestamp, tenant, MCP client, authenticated user, connector, tool, status, and duration, in your Portal dashboard. Parameters and response bodies are never in it.
Are operator/admin actions logged?
Yes — administrative and operator actions are audited, and production access itself is logged. Auditor review of these controls is part of the SOC 2 observation window running now.
What is your incident response process?
Assess and contain → identify affected tenants/data → notify affected customers → remediate → post-incident report. Architecture (tenant isolation, Key Vault custody, hashed secrets) bounds blast radius while we respond.
When would I be notified of a breach?
Without undue delay after confirmation of an incident affecting your data — by email to your account address and via the Trust Center — including what happened, what was affected, recommended actions, and remediation. You hear it from us first.
[ 10 · availability, backup & dr ]
What is your backup posture?
Azure SQL automated backups with point-in-time restore over a 35-day window; restore points land within minutes of live. Backups are encrypted like the database (TDE).
What are your RTO/RPO targets?
Database PITR supports recovery to within minutes of an event. Formal RTO/RPO targets are being finalized as part of SOC 2 documentation — current figures are available through the Trust Center rather than invented here.
Single or multi-region?
Production spans three US regions — Azure Central US, East US, and West US 2 — plus the EU region in Azure Sweden Central. Container Apps auto-scale horizontally with health probes gating traffic.
What’s the impact if StackJack goes down?
AI tool calls pause — that’s the whole blast radius. The gateway is stateless: no queued operations to lose, no stale synced data, and your PSA/RMM systems keep running natively and untouched. Service resumption needs no resync.
[ 11 · privacy, compliance & legal ]
Are you SOC 2 certified?
SOC 2 Type II is officially in progress: we are in the mandatory observation window now, with the final report expected November 2026. Track live status and request audit artifacts at the Trust Center.
ISO 27001, HIPAA, PCI, FedRAMP?
Not held, and we won’t pretend otherwise. No HIPAA BAA is offered (PHI may transit the gateway — consult your compliance team). PCI DSS scope sits with Paddle, our Merchant of Record: StackJack stores no card or payment-instrument data. Azure’s certifications apply as inherited infrastructure only.
Are you GDPR / UK GDPR ready?
Yes by design and by paper: processor for connector operations, controller for account data; Art. 28 DPA available via the Trust Center; Art. 32 measures are this page; SCCs (+ UK Addendum) govern international transfers.
CCPA/CPRA position?
No sale of personal information, no sharing for cross-context behavioral advertising, and data-subject requests honored regardless of the requester’s state.
Is a DPA available?
Yes — request it through the Trust Center or security@stackjack.io. Sub-processor list and change-notification commitment are built into it.
How do you handle billing data?
Paddle is our Merchant of Record — it handles all card data and carries PCI DSS scope. StackJack stores only a Paddle customer reference. Free-tier signup requires no card at all.
Who will you notify about sub-processor changes?
Subscribers via the Trust Center, with advance notice before any new sub-processor processes customer data — the current list is always published there.
[ 12 · company, personnel & vendor management ]
Who is the legal entity?
MSP Automator Labs, LLC — a New Jersey limited liability company doing business as StackJack.io. When you contact us you reach the people who build and operate the product.
Do you carry cyber liability insurance?
Yes — certificates of insurance are available through the Trust Center as proof for your vendor file.
What are your personnel security controls?
We’re a deliberately small, founder-led engineering team — and we describe it that way rather than implying a security org we don’t have. What we claim is provable: least-privilege access, no standing plaintext-credential access, audited production access, and controls under active SOC 2 observation.
How do you manage your own vendors?
Sub-processors are reviewed before adoption, operate under DPAs/commercial terms (including no-training terms for AI providers), and are published with change notification via the Trust Center.
Do you have documented security policies?
Yes — maintained and auditor-reviewed as part of the SOC 2 program, covering governance, access, change, incident, and vendor management. Request them through the Trust Center.
Will you complete our security questionnaire?
Yes — upload your DDQ, SIG, SIG-Lite, or CAIQ at the Trust Center and we’ll complete it against documented controls, promptly — we know it’s on your critical path.
Run your vendor review.
Submit a DDQ, request the DPA and insurance certificates, or track the SOC 2 Type II audit — it’s all in the Trust Center. Prefer a human? security@stackjack.io.
Security brief v2.0 · last updated July 22, 2026 · responsible disclosure: security@stackjack.io (good-faith safe harbor applies)