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-2)
- Encryption
- TLS 1.2+ in transit · AES-256 at rest (database and object storage)
- Authentication
- Teams approvals under your Microsoft 365 sign-in · portal email and password · operator console on Entra ID SSO
- Audit trail
- SHA-256 tamper-evident chain · customer-exportable for independent verification
- Availability
- 99.5% published target · status.ascendcore.ai
- Incident response
- P1: 30-min ack / 4-hr resolution target in business hours · breach notice per DPA Section 10 (72 hours)
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 requests and 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 sealed with AES-256-GCM in a per-org vault in Postgres. Each org's credentials resolve only for that org's traffic, and are never returned to a browser or API response.
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 check it with our standalone verifier (supplied on request): cryptographic proof against later tampering.
Your Identity Provider for Approvals
Approvals made in Microsoft Teams run under your users' own Microsoft 365 sign-in, so your Entra ID MFA and Conditional Access policies apply unchanged. AscendCore never reimplements MFA. The customer web portal uses email and password today; portal SSO is planned.
How the system is built
The architectural specifics most security teams want to verify.
- 1
Multi-tenant by design: shared tables keyed by organization ID, a per-org audit chain, and per-org credential vaults. Phase 2 shipped (May 2026). Phase 3 (per-tenant Teams JWT audience and customer-employee SSO) is planned.
- 2
Deterministic execution layer: 31 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, device enrollment assignment, guest account cleanup, SSO app assignment). 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 and never executes against customer systems. It does see the request text, which can include names and email addresses.
- 4
Customer integrations enabled per-tenant: Okta, Microsoft Entra, M365, Intune, Jira, Confluence, ServiceNow, Freshservice, Slack, Teams. ITSM sources (ServiceNow, Jira Service Management, Freshservice) support ticket ingest with system-native write-back. Each integration runs through that organization's own connection: its own API credentials, or admin consent to AscendCore's multi-tenant Microsoft application.
- 5
Single-region today (US-East-2): Neon Postgres (point-in-time restore over a 6-hour window) + Netlify Blobs + Netlify US hosting. Multi-region failover is planned.
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 vault: customer-entered credentials sealed with AES-256-GCM in Postgres and bound to the organization; platform secrets in Doppler
- ●Inbound webhook integrity: HMAC-SHA256 with timing-safe comparison (Slack) + JWT validation against Microsoft Bot Framework JWKS (Teams)
- ●Role-based access control enforced server-side: administrator and approver roles in the customer portal; demo and guest roles refused on every mutation route of AscendCore's console
- ●Customer API authentication via bearer tokens (Stripe-style format, 256-bit entropy) with per-key rate limiting and revocation
- ●Outbound webhooks signed with an HMAC-SHA256 signature in the Ascendcore-Signature header
- ●Idempotent approvals: duplicate clicks and retries are rejected, and a decided request cannot be decided again
- ●Public uptime monitoring and status page (Better Stack) with 90-day history
- ●Published DPA (GDPR, UK GDPR, CCPA; Standard Contractual Clauses Module Two); countersigned copy on request
Tech E&O + General Liability insurance
Being arranged; not yet bound. A certificate of insurance will be available on request once coverage is in force.
SOC-2 Type I
Planned
Not yet enrolled. Enrollment begins once budgeted, followed by a ~90-day audit window and then certification.
Independent penetration test
Planned
Report shared under NDA for active procurement conversations once complete.
SOC-2 Type II
Planned
After Type I + standard observation period.
Customer-managed encryption keys (BYOK)
Planned
Bring-your-own-KMS for application-level data encryption.
ISO 27001
Planned
Post-SOC-2 alignment for international procurement requirements.
HIPAA-aligned deployment
Demand-driven
Not offered today, and no BAA is available yet. Evaluated if a healthcare customer requires it.
Detection & response
How we detect production incidents, how fast we respond, and how we communicate during them. Severity targets come from our internal incident runbook.
| 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
Better Stack monitors four surfaces (the site, the application, the database, and the integrations aggregator) and probes public endpoints only. Public 90-day uptime history at status.ascendcore.ai.
Application error tracking
Sentry captures errors across client, server, and edge runtimes, configured not to send default personal data; synthetic monitor traffic is filtered out. Operator alerts go to email and Slack.
Customer reports
security@ascendcore.ai for security-classified reports, support@ascendcore.ai for everything else.
Communication during incidents
- Status page update within 15 minutes of severity assignment for any customer-visible P1 (target)
- Update cadence: every 15 minutes during a P1, every 30 minutes during a P2, until resolution (target)
- Post-incident review drafted within 24 hours of resolution (target)
- Security Incidents: notice to affected customers without undue delay and no later than 72 hours after becoming aware, per DPA Section 10
Honesty note on after-hours coverage: Outside business hours, P1 acknowledgment is best effort and may exceed the 30-minute target. There is no paging service or after-hours rotation today; after-hours paging is planned.
Sub-processors
Every third party that processes customer data, why we use them, and where they store it. We use each provider under its standard terms and published data processing terms; under the DPA (Section 7), customers get at least 14 days' notice before a sub-processor is added or replaced.
| Vendor | Purpose | Region | Notes |
|---|---|---|---|
| Netlify | Application hosting, CDN, serverless functions, Blobs operational store | US | Blobs store in US East 2 |
| Neon | PostgreSQL database (audit chain, credential vault) | US-East-2 | Postgres 17 on AWS |
| Cloudflare R2 | Object storage for exports and uploads (AES-256) | Not pinned | Automatic location |
| Doppler | AscendCore platform secrets, including the vault key | US | Holds no customer-entered credentials |
| Anthropic | LLM request classification and the optional IT help assistant (no tools, no execution access) | US | Commercial Terms: no training on customer content; API data deleted within 30 days, with exceptions |
| Resend | Transactional email delivery | US | Notifications can name the target user and action |
| Sentry | Application error tracking | US | Configured not to send default personal data |
| PostHog | Product analytics (page views) | US | Only after cookie consent |
Customer-entered integration credentials are sealed with AES-256-GCM in a per-organization vault table in Postgres and used only for that organization's requests; Doppler holds only AscendCore's own platform secrets. Request records (requester, approver, the target user's name and email, the action, and the outcome) are kept in the operational store for the life of the account; they do not hold chat text or ticket descriptions. Teams messages reach AscendCore through Microsoft's Bot Framework service.
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 is labeled In progress or Planned. 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.
