Skip to content
AscendCore
Approval-First AI

Autonomous where it is safe. Approved where it matters.

AscendCore is approval-first AI for IT operations. The model reads intent and is air-gapped from execution. Every action waits for a named human to approve it, then lands on a tamper-evident SHA-256 audit chain you can re-hash and verify yourself.

Human-in-the-loop on every actionAI air-gapped from executionTamper-evident SHA-256 chainPer-org credential isolation

The autonomous-agent problem

The fastest way to lose trust in automation is to let it act without asking.

The whole market is selling the same promise: the agent just handles it. The question no vendor wants on the slide is what happens the first time it handles it wrong. Against your production identity stack. At 2am. With no human in the loop.

You already know the shapes that fear takes. An autonomous suspension that locks out the wrong VP. An MFA factor reset fired by a prompt-injected ticket. A bulk group change no one can reconstruct the morning after.

In IT operations, the action is irreversible and the blast radius is your whole company. Control is not friction here. Control is the product.

01 · The category

Approval-first, defined.

Approval-First AI: an architecture where the AI classifies intent but is air-gapped from execution, no action touches a production system until a named human approves it, and every decision is recorded to a tamper-evident audit chain.

TRY THE GESTURE

Access Role Change · Priya Patel

Okta · Entra ID · M365 · via Teams

99%

A demo of the gesture. Nothing real executes.

AI air-gapped from execution

The model's only output is a classified intent and a confidence score. It holds no credentials and never calls a production API. Autonomous agents skip this boundary. We made it load-bearing.

A named human at the gate

Every runbook stops at an interactive Slack or Teams approval card before it changes anything. The approver sees the target, the impact, and the runbook, then decides.

Proof by default

Every approve, deny, and execution appends to a SHA-256 chain backed by Postgres. Export it, re-hash it, check it offline. The proof is yours, not ours.

Anchored to what is shipped: 31 production runbooks, server-side RBAC, and a Neon-backed audit chain you can verify live.

02 · The spectrum

Autonomous where it is safe. Approved where it matters.

Approval-first does not mean slow. It means precise about where the gate goes.

Autonomous where it is safe

Triage, intent classification, identity resolution, and simulate-and-validate dry runs all run without a gate. When the work only reads, speed costs you nothing.

Approved where it matters

Anything that writes to a production system (MFA reset, account suspension, group and license changes, offboarding) stops at a human first. The approver sees the target, the impact, and the runbook before they click. Once a named admin approves, the runbook executes in about 52 seconds (tested).

This is not automation with a speed bump. It is automation that knows the difference between reading and writing.

03 · The flow

From Slack to approval to proof.

An IT admin requests an access change and AscendCore runs the approval flowA person sits at a desk on a laptop. On a loop, a request to add Priya to the Finance-Leads group appears, AscendCore proposes the change, an "Approved by Marcus Chen" stamp drops in, Okta, Entra ID and M365 light up with checkmarks, and the action is sealed in a tamper-evident audit chain.DRAdd Priya to the Finance-Leads groupAscendCoreAdd Priya Patelto Finance-Leads groupApproved by Marcus ChenOktaEntra IDM365Logged to tamper-evident audit chainsha256 9f2a7c…e1b7 · block #4012
01Ingest

A request arrives in Slack or Microsoft Teams in plain English.

02Classify

The AI reads it and outputs a structured intent (label, confidence, entities). That is the only thing it does. It holds no credentials and never calls a production API.

The LLM stops at step 02. It never touches steps 03 or 04.

03Approve

A named admin approves or denies on the interactive card. Nothing runs until they do.

04Record

A deterministic runbook executes against your existing stack, and the decision is appended to the tamper-evident SHA-256 chain with actor, target, timestamp, and outcome.

Every one of these rows is independently checkable. Not by us. By you.

An approver reviewing a request on her phone while walking through a sunlit office

04 · The proof

One chain. Every decision. Provable.

Each record's SHA-256 includes the prior record's hash. We just re-computed the entire chain from genesis and every stored value matched, so no record was altered, inserted, or removed. You can reproduce this yourself from the exported CSV.

Append-onlyCryptographically linkedCustomer-verifiable offline
seqactionactorthis_hash
0007mfa_reset.approveda.morgan@acme.com9f4d2a8c…1b3d5f7a
0008account_unlock.approvedsystem7c3a1f9d…d1f3a5c0
0009offboard.approveda.morgan@acme.coma3f5b9c1…d8e0f2a4

Sample chain shown. The live demo verifies the Acme sample data.

Verify a sample chain now

Click Verify. Watch it re-hash every record from genesis. Copy a hash and check it yourself.

Not verified by us. Verifiable by you.

This is one capability inside a documented security posture. See sub-processors, data residency, and the CISO FAQ in the Trust Center.

05 · For your auditors

Evidence for the controls your auditors check.

  • Evidence for: SOC 2 CC7.2 / CC7.3 (system monitoring, change detection). Every governed action is recorded append-only with actor, target, and timestamp.
  • Evidence for: SOC 2 CC8.1 (change management). Each change carries an explicit human approve or deny decision.
  • Evidence for: SOC 2 CC6.1 (logical access). Actor identity is bound into every record's hash.
  • Evidence for: ISO 27001 A.12.4 (logging and monitoring). The chain is cryptographically verifiable end to end.

SOC 2 Type I is planned (about a 90-day window once enrollment begins). AscendCore is not currently SOC-2 certified or in assessment. This export is evidence you can hand your auditor, not a SOC-2 report.

Access review campaigns

Quarterly access reviews run inside the same gate. Snapshot an Entra ID group, decide keep or revoke per member, and every revocation stages the same human-approved runbook as any other change, so a flagged access does not die in a spreadsheet. The closed campaign exports as an evidence bundle: every decision row carries the sequence number and SHA-256 hash of its chain record, re-verifiable offline.

  • Evidence for: SOC 2 CC6.2 / CC6.3 (access reviews, access removal). Every decision is a chained record carrying reviewer identity, timestamp, subject, and outcome.
  • Evidence for: SOC 2 CC6.1 (logical access). Revocations execute only through the human-approved runbook path, and each approval is itself a chained record.
  • Evidence for: ISO 27001 A.5.18 (review of access rights). The snapshot, each decision, and the close-out are independently re-verifiable against the exported chain.

A review campaign produces evidence you can hand your auditor. It is not a compliance program, and completing one is evidence of an access-review control operating, nothing more.

See a review campaign in the demo dashboard

Signals

Signals turns detections from the identity systems you already run into containment proposals with the same human approval in front of every action. The detection source is named on every card, and nothing auto-contains: an approver decides, the runbook executes, the chain records detection, decision, and outcome.

Full security posture, sub-processors, and CISO FAQ live in the Trust Center. Procurement teams can start with the security overview.

06 · The durable bet

Approval-first is not a hedge against bad models. It is a permanent requirement of governed change.

Even if every foundation model became perfectly reliable tomorrow, you would still need the approval record, the named approver, and the tamper-evident chain for audit, compliance, and incident reconstruction. Those do not commoditize when the model improves.

The LLM classifies. A deterministic TypeScript runbook executes. The execution path is reviewable, version-controlled, and identical every run. That is what makes the approval meaningful. You are approving a known action, not a model's improvisation.

And it composes with the ITSM you already run. ServiceNow incidents and Jira issues flow into the same approval gate, and the decision is written back to the originating ticket. No migration: setup guides for ServiceNow and Jira.

The differentiator is the architecture, not the AI.

See the approval gate and the audit chain. Live.

No login. No sales call. Open the live Governance Control Plane demo, click Verify, and watch the entire chain re-hash from genesis.

Open the live demo