AscendCore Security Overview
One-page summary of AscendCore's security posture, architecture, data handling, compliance status, and sub-processors. Safe to share with procurement, legal, or security review teams. For comprehensive Q&A, see the gated materials at /security/questionnaires.
At a glance
The facts a procurement reviewer most often needs in the first 90 seconds.
- Legal entity
- AscendCore, Inc. (Delaware C-Corp, May 2026, Stripe Atlas)
- Product
- AI orchestration platform for IT operations (L1 helpdesk automation)
- Target market
- Mid-market enterprise IT (500–3,000 employees)
- Hosting
- Netlify (US edge) · Neon Postgres (US-East-1)
- Encryption
- TLS 1.3 in transit · AES-256 at rest
- Authentication
- OIDC SSO admin login (Microsoft Entra + Okta) · mandatory IdP-mediated MFA
- Audit trail
- SHA-256 tamper-evident chain · customer-exportable for independent verification
- SLA
- 99.5% monthly uptime · status.ascendcore.ai
- Incident response
- P1 — 30-min ack / 4-hr resolution target · written into customer MSA
Security architecture
Four design choices that shape every other security claim.
Approval-First Architecture
Every automation requires explicit human approval before execution. No autonomous actions, no "AI just decided" surprises. The LLM classifies intent only — it has no execution access. Deterministic runbooks are the load-bearing primitive; chat is the interface layer.
Per-Tenant Credential Isolation
Integration secrets (Okta API keys, Entra client secrets, M365 credentials, Slack tokens) are scoped per organization and managed via Doppler. Each org's credentials resolve only for that org's traffic. No cross-tenant credential bleed possible at the architecture level.
Tamper-Evident Audit Chain
Every approve / deny / execution event is appended to a SHA-256 hash chain backed by Postgres. Each record links to the prior record's hash, so a single altered row breaks chain verification. Customers can export the full chain via CSV and re-run our verification routine independently — cryptographic proof against later tampering.
Mandatory IdP-Mediated MFA
Admin authentication runs through the customer's identity provider (Microsoft Entra or Okta). MFA is enforced at the IdP, never reimplemented on our side. The customer's conditional access policies — device trust, geo-fencing, FIDO2, hardware tokens — apply unchanged.
How the system is built
The architectural specifics most security teams want to verify.
- 1
Multi-tenant by design — per-org schema, per-org audit chain, per-org credential vaults. Phase 2 shipped (May 2026); Phase 3 (per-tenant Teams JWT audience + customer-employee SSO) ships Q3 2026.
- 2
Deterministic execution layer — 13 production runbooks (MFA reset, password reset, account unlock, license assignment, group ops, role change, security alert triage, VPN access, software decommission, Confluence space, distribution list, new-hire provisioning, offboarding). Each is hand-written, deterministic, and audit-emitting — not LLM-generated.
- 3
LLM air-gapped from execution — Anthropic Claude classifies the natural-language ticket into a runbook intent. The runbook itself runs deterministic code against customer integrations. The LLM never sees credentials, never executes against customer systems, never sees individual users' personal data beyond the routing classification.
- 4
Customer integrations enabled per-tenant — Okta, Microsoft Entra, M365, Intune, Jira, Confluence, Slack, Teams. Each integration uses the customer's own API tokens, scoped to the minimum required permissions. Permissions documented in the customer onboarding playbook at /docs/onboarding.
- 5
Single-region today (US-East-1) — Neon Postgres + Netlify US edge. Multi-region failover on roadmap for 2027 once SLA tier > 99.5% becomes a procurement requirement.
Compliance status
Honest about what's shipped vs what's on the timeline. We surface this section in every customer security review.
- ●Approval-first architecture — every automation requires explicit human approval; no autonomous actions
- ●Per-organization credential isolation — Doppler-managed secrets vaults, scoped per tenant
- ●Inbound webhook integrity — HMAC-SHA256 with timing-safe comparison (Slack) + JWT validation against Microsoft Bot Framework JWKS (Teams)
- ●Role-based access control — Owner / Demo / Guest with server-side enforcement on every mutation route
- ●Customer API authentication — bearer tokens (Stripe-style format, 256-bit entropy) with per-key rate limiting and revocation
- ●Outbound webhooks signed — HMAC-SHA256 signature in X-AscendCore-Signature header
- ●Idempotency keys on every mutating endpoint
- ●Public synthetic uptime monitoring — BetterStack, 4 global regions, 3-minute cadence
SOC-2 Type I
Vanta enrollment underway (May 14, 2026). Audit window opens this week; Type I certification targeted Q3 2026.
Master Services Agreement + DPA
In legal review with startup SaaS counsel (May 14, 2026). Standard MSA + DPA templates available to design partners on request.
Tech E&O + General Liability insurance
Binding in parallel with legal pack ($1M/$1M floor). Certificate of Insurance available on customer request after binding.
Independent penetration test
Q3 2026
Scheduled after multi-tenancy Phase 3 + observability story complete. Report shared under NDA for active procurement conversations.
SOC-2 Type II
H2 2027
After Type I + standard observation period.
Customer-managed encryption keys (BYOK)
H1 2027
Bring-your-own-KMS for application-level data encryption.
ISO 27001
2027
Post-SOC-2 alignment for international procurement requirements.
HIPAA-aligned deployment
Demand-driven
BAA template ready; full HIPAA controls activated when first healthcare design partner signs.
Detection & response
How we detect production incidents, how fast we respond, and how we communicate during them. Severity targets are written into customer MSAs.
| Severity | Definition | Ack target | Resolution target |
|---|---|---|---|
| P1 | Production down, no workaround API returning 5xx broadly · audit chain verification failing · customer dashboard inaccessible | 30 minutes | 4 hours |
| P2 | Degraded, workaround exists Single integration impaired (e.g., Slack-only down) · elevated error rate < 5% · slow response under load | 2 hours | 1 business day |
| P3 | Minor / question / enhancement Cosmetic bug · documentation gap · feature request · low-volume third-party drift | 1 business day | Best-effort |
Detection sources
Synthetic uptime monitoring
BetterStack probes 4 critical surfaces (marketing site, dashboard, public API health, integration aggregator) every 3 minutes from 4 global regions. Alerts fire when 2+ regions report down consecutively — eliminates single-region noise. Public 90-day uptime history at status.ascendcore.ai.
Application error tracking
Sentry SDK active across client, server, and edge runtime layers. Every Netlify production deploy creates a release marker tagged to the commit SHA with symbolicated source maps. PII scrubbing on by default; synthetic monitor traffic excluded from event volume. Alert rules: new issue first seen, error volume spike, fatal-level immediate.
Customer reports
Dedicated Slack Connect channels per customer for direct incident communication during business hours. security@ascendcore.ai for security-classified reports, support@ascendcore.ai for everything else. Both route to the on-call rotation.
Communication during incidents
- Status page updates within 15 minutes of severity assignment for any customer-visible incident
- Direct Slack Connect outreach within 30 minutes for incidents affecting a specific customer's tenant
- Update cadence: every 15 minutes during a P1, every 30 minutes during a P2, until resolution
- Post-incident review document drafted within 24 hours, shared with affected customers within 48 hours, action items tracked within 1 week
- Sanitized incident retros posted to the public status page archive for customer-visible events
- Security-classified incidents — 24-hour notice to affected customers per DPA breach notification clauses
Honesty note on after-hours coverage:Until first paying customer signs an MSA with after-hours coverage, P1 acknowledgment outside business hours is best-effort and may exceed the 30-minute target. This is honestly disclosed in the MSA "Operational Scale" section. PagerDuty wiring activates on first qualifying contract.
Sub-processors
Every third party that processes customer data, why we use them, where they store it, and the data-processing terms in effect. Updated continuously; customers receive 30-day advance notice of changes per DPA.
| Vendor | Purpose | Region | DPA / terms |
|---|---|---|---|
| Neon | PostgreSQL database (audit chain + org schema) | US-East-1 | Neon DPA + GDPR addendum |
| Netlify | Edge hosting, CDN, serverless functions | US | Netlify DPA |
| Cloudflare R2 | Object storage at rest (AES-256) | US | Cloudflare DPA |
| Doppler | Per-org integration credential vaults | US | Doppler DPA |
| Anthropic | LLM intent classification (air-gapped from execution; no customer data persisted) | US | Anthropic DPA + ZDR for enterprise tier |
| Stripe | Billing + subscription management | US | Stripe DPA |
| BetterStack | Uptime monitoring + log aggregation | EU/US | BetterStack DPA |
| Sentry | Application error tracking + performance monitoring (PII scrubbing enabled; no customer data persisted beyond stack trace context) | US | Sentry DPA |
| Resend | Transactional email delivery | US | Resend DPA |
| Vanta | SOC-2 evidence collection (during audit window) | US | Vanta DPA |
Customer integration credentials (Okta, Entra, M365, Intune, Jira, Confluence, Slack, Teams) are stored in Doppler-managed per-org vaults and used only to execute approved runbooks. Customer integration data — user objects, group memberships, audit events — is processed in flight against the customer's own systems and not persisted on AscendCore infrastructure beyond the audit-chain row capturing the approve/deny event metadata.
Engage with security review
For deeper procurement diligence — full questionnaire responses, architecture deep-dive, or active deal coordination — start here.
Honesty note: Every claim on this page reflects what's enforced in production today (Live) or what's in active implementation (In progress / Roadmap). If you find a gap between what's written here and what we deliver, that's a bug we want to fix — email security@ascendcore.ai directly and we'll reconcile.
