Aegis 翊玑
Request a demo
Demos Solutions Platform Controls Security Pricing StandardsCompare approachesCustomer accessRequest a demo
Governance

You decide what an agent may do.

Set limits, review requests that need approval and stop work when necessary. Evaluate the authority checks on the execution paths your agents will use.

Set limits Review a policy change Review approvals Understand a stopped action Stop work Inspect the record
Boundaries

Five kinds of limits, set by your team.

The product calls these an operating envelope. A manager can delegate only the authority they already hold; an agent cannot widen its own limits.

Spending

Set budgets and approval thresholds.

Actions

Specify which systems and operations are allowed.

Time

Limit when authority applies and when it expires.

Information

Control what data an agent may read, change or share.

Communication

Specify who the agent may contact and through which channels.

Operating limits editor
Set the rules before the agent acts.

Accountability supports every limit. Link authority to a responsible role and keep a record of delegations. The authority level on a role and the autonomy mode selected for work are different settings; their L-level numbers are not interchangeable.

Checking an action

Allow it, flag it, hold it or block it.

Aegis checks actions against configured permissions and limits. Verify which checks run before execution on the runtime you choose.

Allow or flag

Work within the rules can proceed. An action near a review threshold can be flagged for attention.

Hold for approval

Work needing a person’s decision waits in an approval queue.

Block

Blocking rules reject actions on supported enforcement paths.

Verification rules configured to block destructive actions
The screen shows rules configured to block destructive actions at the lowest autonomy level. These actions were not executed in this capture.
Policy review · fictional example

Review a policy change before applying it.

See the proposed approval limit beside the source wording. A different reviewer checks the change, approves it and applies it in a separate step.

Watch the 77-second exampleRead the story →

From a written policy to a reviewed, saved limit.

Avery submits a change from USD 4,500 to USD 4,000. He cannot approve his own submission. Daniel reviews the source and acknowledges the verification warning before approving. The saved limit changes only when he applies it.

Silent demo · captions includedReview a policy change · 77 seconds
Fictional example: Northstar’s general approval policy, reviewed and saved in the application.

Use fullscreen for a closer look, or read the story →

The example ends at saved governance configuration. It does not demonstrate a transaction using the rule. Independent model verification is unavailable in this recording; Daniel explicitly acknowledges the warning.

Read the story and demo details
  1. Avery submits version 4 of the general approval policy. Northstar’s people and operating records are fictional.
  2. The proposal changes the saved limit from USD 4,500 to USD 4,000. Both source sentences remain beside the rule.
  3. Avery cannot approve his own submission. A different eligible reviewer must decide.
  4. Daniel reviews the source and proposed change. Independent model verification is unavailable.
  5. Daniel acknowledges this flagged rule individually, then approves the changeset.
  6. Approved is not yet applied. The saved limit remains USD 4,500 at this point.
  7. Daniel applies the reviewed changeset separately. The saved limit becomes USD 4,000.
  8. Reopened: the same version and Daniel’s approval remain. This proves saved configuration, not transaction enforcement.

The same document version is reopened with Daniel’s approval retained. Approval and application are separate: the saved limit remains USD 4,500 after approval and becomes USD 4,000 after application.

This is a general approval policy covering all decision classes. It does not demonstrate purchase-category setup, automatic model verification, payment approval or downstream enforcement.

Northstar, its people and records are fictional. Recorded in the local application on 28 September 2026 using Avery’s and Daniel’s accounts. Separate account recordings follow the same versioned change; cuts shorten navigation and reading waits. The recording does not establish production availability.

Download captions (VTT) · Download subtitles (SRT) · Download transcript

Explore your policy review process →

Human decisions

Approval happens in a dedicated queue.

A person can inspect the request and record a decision. Here, Marcus spots the wrong buyer on a submitted invoice and rejects that same request.

Silent demo · captions includedA reviewer rejects the wrong buyer document · 60 seconds
The same request is rejected and processing stops.
Read the transcript

A submitted document names Acme Corporation as buyer, while the reviewer works in Northstar.

Marcus enters the buyer-mismatch reason; the later saved state confirms the decision.

This is a document review, not a payment or mailbox-intake demonstration. Other requests visible in the background are separate cases.

Fictional demonstration. Screenshot walkthrough; saved-record views are labelled.

  1. 00:00:00.000 — One submitted document is read and held for review.
  2. 00:00:07.217 — The same document and run numbers follow it throughout.
  3. 00:00:15.000 — The document names Acme Corporation as the buyer.
  4. 00:00:21.934 — The reviewer works in Northstar.
  5. 00:00:26.462 — The buyer does not match.
  6. 00:00:30.000 — Marcus, the Finance reviewer, enters his rejection reason.
  7. 00:00:37.565 — The filled dialog precedes the saved decision shown next.
  8. 00:00:45.000 — The same request is now rejected. Processing stops.
  9. 00:00:52.650 — This is a document decision. No payment was made.

Download captions (VTT) · Download subtitles (SRT) · Download transcript

Separate simulated spending review · recording download

A separate limit example. An earlier recording pairs a $100 invoice draft with a separately simulated $1,500 request held against a $1,000 review threshold. The reviewer rejects the held request. These are separate scenarios, and no payment occurs.

An invoice reaches its limit. The reviewer decides. · 40 seconds
The operator asks an assistant to review a $100 invoice. In a separate simulated finance check, a $1,500 request is held above the $1,000 limit. Using Marcus’s demonstration account as head of Finance, the operator rejects it. No payment occurs.

Download the original recording or read its transcript

The operator asks an assistant to review a $100 invoice. In a separate simulated finance check, a $1,500 request is held above the $1,000 limit. Using Marcus’s demonstration account as head of Finance, the operator rejects it. No payment occurs.

  1. 00:00:00 — The AI reviews a fictional invoice. Edited recording of a real test.
  2. 00:00:11 — The assistant writes an internal draft. It flags missing evidence for Marcus.
  3. 00:00:19 — Signed in as Marcus, head of Finance.
  4. 00:00:21 — Separate simulated payment check. $1,500 held: above $1,000 review limit.
  5. 00:00:27 — Marcus records why he will reject it. Purchase approval and evidence missing.
  6. 00:00:32 — Marcus rejects the held request. Decision saved. No payment was made.

Download captions (VTT)

Fictional demonstration accounts operated by an automated demo operator.

Download the original recording (embedded English remains).

Inspect the autonomy-review setup
Pending requests for increased agent autonomy
Review who requested more independence and the change it would allow.

The Leadership Inbox shown in the invoice demo is a notification screen. Its “Mark read” action does not approve the underlying work.

Stopped action · fictional example

See which rule stopped the action.

A plan can be approved while a particular action remains restricted. An authorised owner can inspect the relevant rule and decide what needs review.

Watch the 37-second exampleExplore your review process →

The plan is approved. The query is still blocked.

Sofia approves a limited reference check. The analyst’s tool restriction stops the query. Avery then opens the explanation from his own account and sees the matching blocking rule.

Silent demo · captions includedUnderstand why an action stopped · 37 seconds
Fictional example: a stopped reference query and a separate owner lookup of the same current rule.

Use fullscreen for a closer look, or read the story.

Read the story and demo details
  1. Sofia approves a limited reference read. The configured restriction still applies.
  2. The query was refused. A hold of the saved-result screenshot keeps the actual reason readable.
  3. Avery opens the matching explanation from his account. Separate capture; same agent, tool and trust chain.
  4. The current rule blocks this tool. Ask the responsible owner to review the restriction.

The query targets harmless public reference data. The tool is refused before the query executes; no business result is generated.

The film moves from approval to an eleven-second hold of the original saved-refusal screenshot, then to Avery’s separately recorded explanation. Sofia’s permissions did not allow her to open that screen. This is an authorised owner lookup, not an automatic explanation for every user or denial.

The agent, tool and trust-chain context match, and the restriction is unchanged between refusal and lookup. This explains current configuration, not a full historical replay. Other gates were not evaluated. Asking the responsible owner to review the restriction is editorial guidance; no exception, bypass or later successful query is shown.

Fictional organisation, people and records. Captured in the local application on 28 September 2026, with an automated operator using the named accounts. Cuts shorten navigation and exclude sign-in. This recording does not establish production availability or mobile-app support.

Download captions (VTT) · Download subtitles (SRT) · Download transcript

When you need to intervene

Stop an agent or a wider group of work.

Authorized people can stop one agent, one person’s agents, a type of work or company-wide activity. Broader stops require broader authority.

Kill-switch controls for scope and stop mode
“Drain” refuses new work and gives running work a limited time to finish. “Hard stop” requests immediate termination. Neither reverses actions already completed.

Emergency access has an expiry.

Requests for temporary wider access need a different authorized approver. The approval has a time limit and cannot exceed the approver’s own authority.

Revoking authority also removes that authority from dependent delegations. Defined risk conditions can reduce an agent’s autonomy automatically.

Temporary emergency-access request
Emergency access is recorded, time-limited and subject to review.
Across the organization

Let teams work together with clear boundaries.

Make cross-department collaboration explicit, and keep the AI operating model aligned when responsibilities change.

Agree the connection

A bridge connects two accountable roles across department boundaries. Define both sides’ authorization, the purpose and the scope.

Limit the collaboration

Standing or temporary bridges can restrict what is shared and for how long. A bridge does not give either party unrestricted access.

Review organizational changes

Moving a unit recalculates inherited limits and coordinates changes to sharing, bridges and trust. Review any warnings and follow-up work.

Watch a team move and the resulting authority · 50 seconds
Silent demo · captions includedMove a team and inspect its authority · 50 seconds
The saved organization shows the new manager, a revoked old Finance authority link and an active Operations link.
Read the transcript

Records Review moves from Finance to Operations, and Casey’s reporting manager changes.

The later reference read and assistant preview still allow access.

Reporting structure, role authority and information access are separate. This does not demonstrate revocation of the reference access.

Fictional demonstration. Screenshot walkthrough; saved-record views are labelled.

  1. 00:00:00.000 — Records Review starts under Finance.
  2. 00:00:04.675 — Casey reports to Rowan, the Finance lead.
  3. 00:00:10.000 — Change the reporting manager, then move the team.
  4. 00:00:15.444 — Records Review now reports to Operations.
  5. 00:00:20.000 — The app now shows Casey reporting to the Operations lead.
  6. 00:00:25.044 — Her Records Review assistant remains linked to her role.
  7. 00:00:30.000 — The old Finance authority link is revoked.
  8. 00:00:35.526 — The new Operations link is active.
  9. 00:00:40.000 — Casey can still read the reference after the move.
  10. 00:00:45.495 — The assistant preview also allows access.

Download captions (VTT) · Download subtitles (SRT) · Download transcript

Collaboration and change boundaries

Bridge enforcement depends on the operation and the access context supplied. Organizational changes include best-effort downstream updates, so a move is not an atomic guarantee that every dependent system has changed. Validate the affected permissions and work paths.

These are organization and authority controls. Agent-to-agent coordination is a separate capability.

See what changes when Finance permission is removed

Finance returns an answer while its permission is active. After the permission is removed, the next Finance task is refused. These labelled review pages show saved results from fictional accounts operated by an automated demo operator.

Labelled saved-result review page. Before removal: Finance returned an answer. The separate Operations task was allowed but returned no answer text.
Before removal: Finance returned an answer. The separate Operations task was allowed but returned no answer text.
Labelled saved-result review page. After removal: Finance was refused. Operations kept permission but again returned no answer text. This demonstrates the Finance permission boundary, not two completed analyses.
After removal: Finance was refused. Operations kept permission but again returned no answer text. This demonstrates the Finance permission boundary, not two completed analyses.

This repeat followed a correction to an earlier failed permission check. It does not test every expiry, direction or information-sharing rule. The separate fix for empty answers has no new recorded run here.

See the separate shared-handover example for specialist reuse and a review of the unchanged saved output. →

For everyday discussion, colleagues can review an agent’s summary before sharing it in a workspace topic. A recorded next step stays distinct from a formal approval. See how the team conversation works →

Information and instructions

Give agents the right information for their role.

Control what agents can consult and how organizational instructions are kept current.

Clearance and scope

Information classification and organizational access are separate checks. A senior job title alone does not grant access to every record.

Publish and acknowledge

Publish a directive to selected units, track acknowledgement and supersede or withdraw it when instructions change.

Review lasting changes

Review knowledge before publication and proposed procedures before accepting them. Decide which past work may inform future procedures.

Acknowledgement is not proof that every action complied. New learning exclusions do not automatically erase all historical content.

Explore knowledge and learning →
Silent demo · captions includedReference access, then a separate acknowledgement · 63 seconds
Records Review returns the saved phrase with its source; Operations cannot read it with its current permissions. Casey later records one acknowledgement.
Read the transcript

Two assistants receive the same question about a published reference. A separate leadership message later targets two teams.

Avery submits the reference and Rowan reviews it before publication. Casey’s later action records reading of the separate message.

The 33-second chapter transition separates the scenarios. One acknowledgement and two target teams are different counts; neither proves instructions were followed or full coverage.

Fictional demonstration. Screenshot walkthrough; saved-record views are labelled.

  1. 00:00:00.000 — Avery submits the reference. Rowan reviews it.
  2. 00:00:04.230 — The reviewed reference is then published.
  3. 00:00:08.000 — The published reference is visible in the app.
  4. 00:00:12.488 — It contains the saved review phrase.
  5. 00:00:16.000 — Both assistants receive the same question.
  6. 00:00:19.775 — The question does not contain the saved phrase.
  7. 00:00:24.000 — Records Review returns the phrase and cites its source.
  8. 00:00:28.500 — Operations cannot read it with its current permissions.
  9. 00:00:33.000 — A separate leadership message targets two teams.
  10. 00:00:38.393 — No acknowledgement has been recorded yet.
  11. 00:00:43.000 — Casey marks the message as read.
  12. 00:00:45.735 — One acknowledgement is saved.
  13. 00:00:48.214 — This confirms acknowledgement, not that it was followed.
  14. 00:00:53.000 — The app shows one reading confirmation and two target teams.
  15. 00:00:58.128 — These are separate counts.
  16. 00:01:00.350 — They do not show full coverage.

Download captions (VTT) · Download subtitles (SRT) · Download transcript

Two separate examples

00:00 · Who can use the reference00:33 · Send and acknowledge a directive

The second example shows receipt of an instruction, not proof of compliance.

Audit and assurance

See what happened and who authorized it.

Review the recorded action, the rules that applied and its outcome. Search and export the log for investigation or review.

Follow one answer into its estimated cost and signed record → The record belongs to that answer, and the signature check occurs afterward. It is not a check performed before the work.

Inspect the earlier audit-log screen and its limits
Audit log and assurance status
In this capture, independent assurance is not established. The screen labels its findings as advisory; this is not evidence of an independently verified audit.
Inspect separate integrity and framework checks
Audit integrity panel showing a checked cryptographic chain
A separate integrity capture reports 11 checked entries. This is a specific check, not a certification of the whole deployment.
Framework status showing unassessed controls
The framework view distinguishes assessed and unassessed controls.
Review security and deployment

Test the controls that matter to you.

Choose a task that should proceed, one that needs approval and one that must be blocked. Review the outcomes with your team.

Request a demo Watch the demos