The authorization flow

What has to be true before an agent-proposed action is allowed to proceed.

An authorization layer is only worth the name if it decides at the moment of the action — not afterwards, in a log. This page lists every capability that claim requires, the demonstration that proves it, and its exact status today.

SigmaX never holds, trades, or moves capital, and does not route customer capital. It decides whether a proposed capital-linked action is permitted, who must authorize it, and what record proves that afterwards.

Capability status

The claim, the demonstration, and where it stands.

Ten capabilities an authorization layer must have — each with the demonstration that proves it and its status today. Measured against what runs, not the roadmap: a row reaches “In place” only when the demonstration beside it can be run on request.

6 IN PLACE4 PARTIAL0 PLANNED

Runtime enforcement

IN PLACE
Demonstration

A refused ActionIntent cannot bypass SigmaX and proceed.

Status today

An agent can create at most a draft, human-gated proposal. There is no execution path in the enabled product to bypass.

status is measured against what runs today, not the roadmap · a row reaches In place only when the demonstration beside it can be run on request

One workflow, end to end

Twelve steps. One held decision. One replayable record.

The flow runs on its own until step six — where it stops, because stopping is the product.

RUNNINGSTEP 01 / 12

An agent proposes

A research agent, copilot, model, or internal system proposes a capital-linked change — a model-portfolio shift, a rebalance, an exception request.

Refused along the way
  • A silent approval or a quiet downgrade — the flow holds instead.
  • Approval on a model's behalf, or silence read as consent.
  • A swapped instrument, size, or destination inheriting the authorization.
auto-plays · click any step to jumpsample run · SigmaX never holds, trades, or moves capital

Walk the same sequence in your browser against sample data, or ask for it against one of your own historical decisions under a design-partner engagement.

One vocabulary

Every layer has exactly one name.

A buyer, a security reviewer, and an engineer should be able to point at the same object and use the same word for it. These names are stable across the product, the API, and the audit record.

Category
Agent authorization / action control
Entry workflow
Regulated capital decisions
Platform
SigmaX Capital Action OS
Governed request
ActionIntent
Operational context
Capital Twin
Policy
CapitalMandate
Deterministic control
Preflight
Human authority
Approval and delegation layer
Permitted boundary
Agent Gateway and route state
Evidence
Decision Record, replay, and Auditor Pack
Continuous control
Drift Radar
Who reads this, and for what

Three readers. One control surface.

The same authorization decision answers a different question for each reviewer. None of these are outcome guarantees — they are the properties of the control, stated as what the system does.

Security and identity

CISO, head of identity, AI-security lead
  • Identity for non-human callers
  • Least-privilege, route-scoped permissions
  • Action-level authorization, not just logging
  • Fail-closed policy enforcement
  • Scoped and expiring access
  • Complete decision and activity records
  • Revocation and exception containment

Compliance, risk, and legal

CCO, model risk, general counsel
  • Mandate-to-action traceability
  • Evidence provenance and versioning
  • Named human responsibility and delegation
  • Supervisory-review records
  • Retention and deterministic replay
  • Exception and override evidence
  • Defensible audit production

Investment operations

Ops lead, workflow owner, product owner
  • Faster review without removing human authority
  • Fewer manual handoffs between systems
  • Standardized approval states
  • Controls reusable across agents and workflows
  • Measurable review and exception time
Supervisory posture

Agentic systems sit outside the traditional model-risk frame. The controls still have to exist.

Published supervisory material on model risk expressly places generative and agentic AI outside its scope, and leaves each institution to determine appropriate controls under its own risk-based governance. Separately, published examination guidance for broker-dealers treats existing obligations as technology-neutral and points firms at supervision, testing, monitoring, recordkeeping, change management, output review, and accountable human oversight.

SigmaX operationalizes the institution-specific layer that sits underneath those expectations: a recorded authorization decision, the evidence it rested on, the named person who authorized it, and a record that can be replayed.

What this is not
  • Not a certification, approval, endorsement, or registration by any regulator, standards body, or analyst firm.
  • Not a representation that any rule, letter, or guidance requires SigmaX or any similar product.
  • Not legal, compliance, tax, or investment advice, and not a determination your firm can outsource.
  • Not a claim that using SigmaX produces any particular examination, audit, or supervisory outcome.

Your firm determines which obligations apply to it and whether any control satisfies them. SigmaX records the determination and holds the action until it is made.

Interoperability
Draft profile — v0.1

The ActionIntent Interchange Profile.

An authorization layer that only one framework can call is not infrastructure. The profile below is the field-level shape another agent framework, identity provider, or governance platform would need to drive the same flow. It is published as an interface, not an implementation: the mandate logic, evidence-sufficiency evaluation, policy combination, and promotion gating behind it are proprietary and deliberately not described here.

agent identity
Which agent, run, and provider originated the request.
requested action
The capital-linked action being proposed.
target resource
The account, portfolio, or Capital Twin it applies to.
required authority
The approval role the action needs before it may proceed.
policy decision state
Permitted, held, proof-required, or refused.
evidence references
The proof objects bound to the decision, by hash.
approval metadata
Who authorized, under what scope, at what time.
permitted route
The destination and action scope that were authorized.
expiry
When the authorization ceases to be valid.
revocation
Whether and when the authorization was withdrawn or superseded.
audit event ids
The lifecycle events that reconstruct the decision.

The live request and response shapes are published in the public OpenAPI document. No conformance run against a second agent framework has been published yet; when one is, it will be linked here rather than described in advance.

Compliance disclaimer

SigmaX provides capital decision intelligence, scenario analysis, and authority workflow software. SigmaX does not provide investment advice. SigmaX does not place trades, move funds, route customer capital, or manage client capital. Shadow/simulated/paper/backtested results are not live trading results. No result is a guarantee of future performance. Human approval is required before any capital-linked action.

Where SigmaX uses AI, it is governed as assistive software: truthful capability claims, human oversight, traceable records, disclosure of AI assistance, and no capital authority. SigmaX designs AI controls with reference to applicable securities obligations, FINRA existing-rule guidance, SEC AI-claims discipline, NIST AI RMF-style risk management, and EU AI Act transparency readiness. This is compliance-readiness design, not a claim that every deployment or jurisdiction-specific use has completed legal review.

Run this against one of your own workflows.

A design-partner engagement takes one existing capital workflow and replays it — first historically, then alongside live activity — to show what would have been permitted, held, or refused, and what record each disposition produces.