Build, govern, and run agents

Nuroen.AI is an enterprise Agentic AI platform for building, governing, and operating AI agents over real systems — with runtime enforcement, progressive governance, and a full audit trail. Build an agent in minutes, not hours, and make every enterprise system AI-enabled.

This guide opens the live product. It is not a second walkthrough of the marketing homepage. You land on the portal Home in explore mode, look around, and create an account only when you try to run something.

What you will do#

You can build an agent in minutes. Start from 108+ prebuilt agents across HR, IT, Finance, Manufacturing, and Marketing, connect systems with 200+ connectors and components, and deploy with governance built in. Credentials for those systems live in the tenant runtime vault, not in the client.

Open Get Started#

Get Started opens the Nuroen portal Home in explore mode. You see the live product first. You do not need an account to look around.

The same action appears in more than one place on this site. All of them hand off to the portal — they do not keep you on the marketing page.

1. Open Get Started from the header, or Get Started Free from the homepage hero. Explore the product on the hero is the same portal Home.
2. You land on the portal Home — the Web Platform command center, not this documentation page.
3. Creating an account is prompted when you try to run something, not when the page loads.
4. Use Book a demo if you need a guided walkthrough instead of exploring alone. Contact sales if procurement needs a conversation first.

If you already have an account#

Use Sign in in the header. It opens the same Nuroen portal (login). New accounts start from Get Started on that portal — not on this marketing site.

Sales questions go to sales@nuroen.ai. Product help goes to support@nuroen.ai.

Look around first#

Explore mode is intentional. The portal Home is the product, not a signup wall.

You can read the workspace, open panels, and follow the same information architecture you saw on Platform: one lifecycle (Design, Govern, Deploy, Operate, Scale) and two interfaces (Web Platform in the cloud, agentic IDE when you launch the builder). Execution — simulate, publish, or run — is the gate. That is when Nuroen asks you to create an account.

Until then, treat the portal as a map:

• Workspace — where agents, runs, and policy live once you have a tenant.
• Catalog — 108+ prebuilt agents, plus skills, templates, and knowledge packs. See Agent catalog.
• Builder chrome — the visual canvas you will use after Define, Confirm, Validate, Build.
• Governance and operations — the same envelope that stays on when you later run. See Governance at runtime.

Nothing you click in explore mode meters credits. Credits start when a model call is about to run, and only after an account exists.

Start free#

No credit card for trial · Governance on by default · Export audit anytime.

Start free and scale when you are ready. Every plan includes governed agent building, provenance, and credit-based usage — you pay for what you run. You do not need a credit card to start the trial.

Seats versus credits#

Seat pricing covers the workspace, governance, and collaboration. AI usage runs on credits — Nuroen's billing unit for model calls.

Credits are checked before a model call, not after, so the cost ceiling is known before a run starts. Declined off-policy or ungrounded requests spend zero tokens. Approved runs write usage events to a tamper-evident ledger. Plan names and rates live on Pricing, not in this guide. Actual rates depend on model routing and your tenant rate table.

Governance is included on every tier — policy gates, provenance, and approvals are the floor, not an add-on. You can upgrade, downgrade, or cancel later. Start solo on Free, grow into Pro, and talk to sales for Enterprise when compliance demands it.

How a run is billed#

A typical agent turn scales with model tier and prompt length. A RAG-grounded answer meters retrieval plus generation as one governed run. In a multi-step workflow, each model call in the graph is checked before spend; a failed policy gate never burns tokens mid-run.

After you can run#

Once you can execute in the product, pick one path. Every path stays under the same runtime governance. You do not turn safety off to finish the quickstart. L2 (policy-gated) is the production autonomy default.

If you would rather not start from a blank description, install from the catalog first, then bind connectors. If the job is unique, use the four gated steps. If security or GRC needs the envelope before anyone builds, read governance first.

Governance stays on#

Governance is enforced at runtime — safe by default. Controls are not optional UI toggles.

Every agent ships bounded, auditable, and cost-controlled from its first save. High-impact actions still pass scope, confidence, policy, approval, and budget. One fail stops the action and hands humans the context. You can export audit anytime.

This quickstart does not replace the governance guide. Keep that envelope on while you finish the first path.

Preview vs the product#

The homepage Try ICARUS lab lets you describe intent in plain language, preview governed workflows, and explore templates without signing up. ICARUS interprets intent, selects skills, wires connectors, and inserts governance gates — before anything executes.

That lab is preview-only. It is not a tenant. It does not meter your credits. It does not replace Get Started. Sign up (via Get Started) to run agents on your systems.

If you get stuck#

Stay on this page for the common questions below. If you still need a person:

• Book a demo for a guided walkthrough.
• Contact sales for procurement or a security pack.
• Email support@nuroen.ai for product or account help.

Next: build your first governed agent or read governance at runtime.

This guide builds your first governed AI agent on Nuroen.AI. You describe a job in plain language. Nuroen returns a reviewable specification of skills, connectors, policies, and knowledge — not a blank canvas or a raw prompt. Problems surface in the build path, not after go-live.

Restraint is the foundation, not a toggle. Every agent ships bounded, auditable, and cost-controlled from its first save. You do not turn governance off to finish the build. You can build an agent in minutes, not hours — and the same runtime envelope stays on whether you start from a description or a catalog install.

What you will do#

This path is Define → Confirm → Validate → Build. Conversational authoring emits a schema-constrained specification — never free-form code, never an unvalidated graph shown as ready to run.

Choose a starting path#

Pick one. Every path uses the same canvas, the same credential-ref split, and the same runtime governance.

If the job is unique, start from a description. If you would rather not start from a blank brief, install from the catalog, then customize. Marketplace installs still validate against your policies, data, and connectors before they ship.

Before you start#

Do this before Define. The four gates still run on the Nuroen portal, not on this documentation page. You can build a first governed agent in minutes — this checklist keeps the first session from stalling on signup, an empty approval gate, or treating the marketing lab as a workspace.

You do not need code, a model name, or a drawn canvas to start. Domain experts describe the job in plain language and get back a governed specification — not a blank canvas or a raw prompt. Governance is on by default. You do not turn it off to finish.

Open the product#

Get Started (header) and Get Started Free (homepage hero) both open the portal Home in explore mode. Explore the product is the same landing. You do not need an account to look around.

Creating an account is prompted when you try to simulate, publish, or run — not when the page loads. Full handoff: Start in the product.

Nothing you click in explore mode meters credits. Credits start when a model call is about to run, and only after an account exists. No credit card for the trial. Start free and scale when you are ready.

You do not need the agentic IDE for this path. Open Get Started on the portal; launch the builder from there when you are ready.

If you already have an account#

Use Sign in in the header. It opens the same Nuroen portal (login). New accounts start from Get Started on that portal — not on this marketing site.

The builder chrome — catalog, canvas, governance, operations — lives on the portal. This documentation page cannot show the signed-in workspace.

Sales questions go to sales@nuroen.ai. Product help goes to support@nuroen.ai.

What you need#

Have a job in mind. Optional: which systems it should call, and who signs off high-impact work. Validate later hard-blocks an unauthenticated connector, a missing secret, a type-mismatched edge, and an approval gate with no assignee — so name an approver before you treat the graph as ready to run.

You do not need a credit card, a named model, free-form code, or to disable runtime governance. L2 (policy-gated) is the production default. Drafts arrive safe-by-default: least-privilege scope, required grounding, and a capped budget.

What this page is not#

The homepage Try ICARUS lab is preview-only. It does not create a tenant, meter your credits, or replace Get Started. Use it to see how intent becomes a governed workflow. Ship the first agent in the product.

If you want a person on the call instead of building alone, Book a demo. Contact sales if procurement needs a conversation first.

The four gates#

Building a governed AI agent on Nuroen.AI is four sequential steps: Define → Confirm → Validate → Build. Each gate must clear before the next one starts. Problems surface in the build path — missing connectors, empty approval gates, ungrounded knowledge — not after go-live.

This is the same four-gated path as Features and Why Nuroen. Conversational authoring emits a schema-constrained specification — never free-form code, never an unvalidated graph shown as ready to run. You do not need a canvas, a model name, or a prompt file to start.

These are build-time gates. After publish, every action still passes the runtime envelope in Governance at runtime — scope, confidence, policy, approval, budget. Clearing Build does not turn those off.

How the four gated steps work#

Skip a gate and the next one does not start. Validate still hard-blocks an unauthenticated connector, a missing secret, a type-mismatched edge, and an approval gate with no assignee.

What each gate produces#

You can still install from the catalog or connect a system first. Those paths rejoin here — marketplace installs still confirm, validate, and build against your policies.

What the governed specification looks like#

The draft Nuroen returns is conceptual — not a public API path and not REST. Keep this shape in mind while you write the job in Define.

# Governed specification — conceptual, not a public API path
outcome: describe-the-job
skills: [versioned]
connectors: [credential-refs]
knowledge: [authorized-sources]
policy:
  autonomy: L2
  grounding: strict

• outcome — the job in natural language.
• skills — versioned capabilities, not a one-off prompt.
• connectors — credential refs. Secrets stay in the tenant runtime vault.
• knowledge — authorized sources only. Strict, role-scoped by default.
• policy — L2 (policy-gated) is the production default. Grounding stays strict.

Drafts arrive safe-by-default: least-privilege scope, required grounding, a capped budget. Capability is raised only where justified.

Define#

Gate 1 of 4. Describe the job in plain language. Domain experts describe what the agent should do and get back a governed specification — not a blank canvas or a raw prompt.

Tell Nuroen what the agent should achieve. It extracts goals, constraints, and capabilities, then drafts a structured outline you can refine. Conversational authoring emits schema-constrained JSON, never free-form code. Nothing unvalidated is shown as ready to build.

Drafts arrive safe-by-default: least-privilege scope, required grounding, and a capped budget. Capability is raised only where justified — so the people closest to the work can build, and the platform keeps the restraint.

What to describe#

Write the outcome, the systems involved, and where a human must approve. Example:

“When a new hire is confirmed, open the ITSM onboarding ticket, attach role and manager, notify the hiring manager, and wait for approval before any access is provisioned.”

You do not need to name models, write prompts, or draw nodes yet. That is Confirm and Build.

What the specification includes#

• Skills — versioned capabilities you attach to the agent, not a one-off prompt. Build skills once, attach them from the canvas for fleet-wide reuse.
• Connectors — systems the agent may call. The canvas stores credential refs, not secrets. See Connect a system.
• Policies — autonomy, approvals, and budget inherited from the org envelope. Governance at runtime stays on. L2 (policy-gated) is the production default.
• Knowledge — authorized sources the agent may retrieve from. Strict, role-scoped knowledge is the default; general-purpose drift is blocked.

Confirm#

Gate 2 of 4. Approve scope and guardrails before anything is wired to production systems.

Builders confirm scope, connectors, and governance settings before any canvas is generated. The specification is a locked draft: outcome, linked systems, and policy gates must be accepted so the build starts from an agreed contract rather than an inferred graph.

Nothing in this step executes. Confirm is review — not deploy. High-impact work still pauses for sign-off later at runtime; you are accepting the envelope here, not bypassing it.

Validate#

Gate 3 of 4. Validation blocks broken flows and missing safeguards. Automated validation hard-blocks production when any of these are true:

• a connector is unauthenticated
• a secret is missing
• an edge is type-mismatched
• an approval gate has no assignee

Every agent stays within its mandate and grounds only in authorized knowledge — enforced before action, not after an incident.

When strict RAG is on (the default): the run retrieves before reasoning, cites sources, and can decline off-task queries before any model call. Declined off-policy or ungrounded requests spend zero tokens. Role-scoping blocks general-purpose drift. Answers stay source-backed.

Simulation in the product surfaces the same policy and connector blockers before deploy. See Platform APIs for the graph-simulation overview — not a REST catalog.

Build#

Gate 4 of 4. The governed canvas is generated only after the gates clear. Nuroen drafts the graph. You refine it. No code is required.

You compose visually: triggers, skills, conditions, and connectors on one canvas. Then you connect systems and knowledge, simulate, and publish.

Compose on the canvas#

Arrange nodes until the flow matches the job. Drag skills, tune conditions, and keep typed edges valid — the same checks from Validate stay live on the canvas.

Connect systems and knowledge#

1. Bind connectors as credential refs. Secrets stay in the tenant runtime vault. Deploy is blocked until every connector is authenticated.
2. Attach knowledge packs and versioned skills on the same canvas. Access controls apply so the agent only sees what it is permitted to know.
3. Keep runtime governance on. You do not turn it off to finish the graph.

Simulate, then publish#

Run scenarios before go-live. Inspect validation checks. When the graph is clean, publish.

Every save creates an immutable version. Runs pin the version they executed. Promote with policy gates, provenance, and an audit trail already attached — and roll back if you need to.

See the Platform Builder panel for the live capability, not a second marketing walkthrough.

After the first save#

The artifact is audit-ready from day one: policy, connectors, and provenance attached. You did not earn governance later.

Rates and plan names live on Pricing. This guide does not list credit rates.

Governance stays on#

Every agent is bounded, auditable, and cost-controlled from its first save. Policy binds design-time validation and runtime enforcement so every action passes the same gates — studio, schedules, and external systems included. There is no bypass.

High-impact actions still pass scope, confidence, policy, approval, and budget. Approve, reject, or modify before anything proceeds. Every decision is logged.

Read the full envelope in Governance at runtime — Policy, Gate, Supervise, Prove.

Preview vs the product#

The homepage Try ICARUS lab shows how ICARUS interprets intent, selects skills, wires connectors, and inserts governance gates — before anything executes. It is preview-only. It is not a tenant, it does not meter your credits, and it does not replace this path.

If you get stuck#

Stay on this page for the common questions below. If you still need a person:

• Book a demo for a guided walkthrough.
• Contact sales for procurement or a security pack.
• Email support@nuroen.ai for product or account help.

Next: connect a system, browse the agent catalog, or read governance at runtime.

The agent catalog is Nuroen’s marketplace for reusable AI assets. Browse 108+ prebuilt agents alongside reusable skills, workflow templates, connectors, and knowledge packs. Install in one click. Customize on the same visual canvas as Builder. Deploy through the same governed pipeline as a from-scratch build.

This is the marketplace path: Browse → Install → Customize → Deploy. Installation is a starting graph, not a production skip. Marketplace installs still validate against your policies, data, and connectors before they ship.

# Marketplace path — conceptual, not a public API path
journey: [browse, install, customize, deploy]
catalog: prebuilt-agents
install: clone-graph
canvas: same-as-builder
deploy: governed-pipeline

If the job is unique, build from a job description instead. Preview templates on the homepage Try ICARUS lab — that gallery is preview-only. Ship in the product catalog.

Browse#

Search a curated catalog of 108+ enterprise-ready agents, reusable skills, workflow templates, connectors, and knowledge packs — organized by industry, capability, and certification status.

The catalog is the fastest start when you would rather not begin from a blank brief. It is not a second product. An installed agent still binds connectors as credential refs, still hits Validate, and still runs under runtime governance.

Search and filter#

Open the catalog in the product and filter by what the job needs, not by a vendor list this page invents.

Industry packs group related agents so a team can start from a shared pattern instead of a one-off graph. Certification status is a listing badge — it does not replace your org’s policy envelope.

What you can install#

The marketplace is a reusable library. Install an agent for a whole job, or install a piece and compose it into a graph you already own.

Build once and reuse across teams. Skills, templates, knowledge packs, and connectors install into other workspaces the same way agents do.

Certified listings#

Every featured asset is reviewed before publication so you start from a trusted building block, not an unverified prototype. Certification is about the listing. Your tenant still supplies connectors, knowledge, approvers, and policy.

A certified agent does not skip simulation, does not authenticate systems for you, and does not raise autonomy past L2 (policy-gated) unless the org has justified it.

Install#

Install certified assets directly into your workspace. Nuroen validates dependencies, clones the workflow graph, and wires knowledge refs — ready for customization in seconds.

Install is an import. It copies the graph into your tenant. It does not publish. It does not run. Creating an account is prompted when you try to install, simulate, publish, or run — not when this documentation page loads.

One-click import#

Pick a listing and install. The workspace receives a clone you own: nodes, typed edges, skill stubs, and knowledge refs. You can edit every node. You cannot edit the publisher’s original.

Replaying install does not duplicate the source listing. Each import is a new workspace graph. Each later save creates a new immutable version of your clone.

What the clone includes#

Dependencies are checked at import so a missing skill or knowledge ref surfaces immediately. A connector stub is not a live credential. Authenticate in Connect a system, then bind the ref on the canvas.

What install does not do#

• Authenticate a CRM, ITSM, warehouse, or custom API. That is Connect, then Bind.
• Attach your knowledge packs. You still choose what this agent is allowed to retrieve.
• Name an approver. An approval gate with no assignee hard-blocks production.
• Publish or run. Promote is a later step on the same governed pipeline.

If you only needed a connector definition, install it from the connector catalog and stop there. An agent listing that expects a ticketing system still needs a live credential ref before publish.

Customize#

Open the installed asset on the same visual canvas as Builder. Bind connectors, attach knowledge packs, apply policy gates, and refine the workflow to match the business.

Customize is a graph edit, not a fork into a different tool. Triggers, skills, conditions, connectors, and outputs stay typed. Conversational authoring can patch the clone as schema-constrained JSON — never free-form code, never an invented connector, never an unvalidated graph shown as ready to run.

Same canvas as Builder#

Arrange nodes until the flow matches the job. Drag skills, tune conditions, keep typed edges valid. A type-mismatched edge hard-blocks production the same way a missing secret does.

You are not locked to the listing. Swap a skill, add a branch, remove a step the org does not need. Each save is a new immutable version of your clone. Production runs pin the version they executed.

See First agent for how the same canvas works on a from-scratch build. Catalog clones enter at Customize; they still pass Validate before Build is treated as shippable.

Bind connectors and knowledge#

1. Bind connectors as credential refs. Secrets stay in the tenant runtime vault. Deploy is blocked until every connector is authenticated.
2. Attach knowledge packs and versioned skills on the same canvas. Access controls apply so the agent only sees what it is permitted to know.
3. Keep runtime governance on. You do not turn it off to finish a marketplace graph.

A catalog agent that expects a ticketing system, a warehouse, or a CRM still needs a live ref. One-click install of a connector definition does not authenticate it. Install, then Connect, then Bind.

When strict RAG is on (the default): the run retrieves before reasoning, cites sources, and can decline off-task queries before any model call. A knowledge pack on the listing is a starting ref. You still attach the packs this tenant authorizes.

Apply policy before you ship#

Drafts arrive least-privilege: required grounding, a capped budget, and the inherited policy envelope. L2 is the production default on the L0–L4 ladder. Raise autonomy only where the org has justified it.

Name an approver for high-impact writes. High-impact actions pause for sign-off with full context. An empty approval gate is a publish blocker, not a courtesy prompt.

Model routing still picks the cheapest capable model that clears residency and budget. A listing does not pin a provider for you unless you set that policy.

Deploy#

Promote through the same governed release pipeline as custom-built agents — validation, policy, provenance, and monitoring from day one.

There is no silent auto-deploy from the marketplace. Clearing install does not ship to production. Simulate, clear blockers, then publish. The published graph pins an immutable version. A run executes that version.

Same pipeline as a from-scratch build#

Same governance whether you build or install. You do not earn an audit trail later. The artifact is audit-ready from the first save of the clone.

Simulate before you promote#

Run scenarios in the product before go-live. Simulation surfaces the same policy and connector blockers Platform APIs describe — it does not replace runtime gates after publish.

The homepage Try ICARUS lab is preview-only. It does not create a tenant, meter your credits, or replace Simulate in the workspace.

When the graph is clean, publish. Roll back to a prior immutable version if you need to. Clients share one schema; this page does not list REST paths.

After publish#

Rates and plan names live on Pricing. This guide does not list credit rates.

See Platform Marketplace for the live catalog, then connect a system or build your first agent. Keep governance on — you do not turn it off to finish a marketplace deploy.

Connectors are how agents take real actions in the systems the business already runs. Discover the catalog, authenticate once, bind a credential ref to the agent graph, then act under runtime policy. Secrets never sit on the canvas. They never reach the client.

This is the integration path: Discover → Connect → Bind → Act. Authenticate once. Store a credential ref. Reuse the same governed connection from staging to production.

# Connector lifecycle — conceptual, not a public API path
discover: catalog
connect: [oauth, api-key, sso]
store: tenant-runtime-vault
canvas: credential-ref
act: runtime-policy

Agents never reach a system you have not credentialed. An unauthenticated connector hard-blocks publish — the same class of check simulation and Validate use on the build path.

Discover#

Search 200+ pre-built integrations across databases, CRMs, ITSM, cloud platforms, collaboration tools, MCP servers, and custom APIs — organized by category, with one-click install.

The catalog is the enterprise integration library, not a second product. Catalog agents you install from the marketplace still bind connectors here. A from-scratch build on First agent uses the same library.

Browse by category#

Filter by what the system does, not by a vendor list this page invents. Open the connector catalog in the product and search by category:

ERP, data warehouses, document stores, and webhooks sit on the same path. Anything the agent reads or writes must go through a connection you authenticated — including knowledge sources used for strict RAG.

What you can connect#

Pre-built connectors cover common enterprise scenarios. Custom APIs cover the rest. MCP servers extend the fabric without secret sprawl: the server is a capability, the credential still lives in the vault.

Webhook and event-driven triggers belong here too. An inbound event is still a connected system. Correlation IDs keep those events aligned with the run that handled them.

One-click install adds the connector definition to the workspace. It does not authenticate it. Install, then Connect, then Bind. A catalog agent that expects a ticketing system, a warehouse, or a CRM still needs a live credential ref before publish.

Connect#

Configure OAuth, API keys, or enterprise SSO. Nuroen validates the connection, encrypts the credential in the vault, and confirms health before any workflow can reference the integration.

Authenticate once. Every graph that needs that system binds the same connection. You do not paste a key into a node, a prompt, or a client payload.

Authenticate once#

Pick the method the target system supports:

Connectors use a shared SDK for auth, retry, checkpointing, and idempotency. Replaying the same input must not create duplicate tickets, records, or ledger entries. You do not write that retry logic on the canvas.

Creating an account is prompted when you try to connect, simulate, publish, or run — not when this documentation page loads. Explore mode does not meter credits.

The tenant runtime vault#

The canvas holds a credential ref. The secret stays in the tenant runtime vault — never in the control plane, never in the builder client, never masked-in-transit to the browser.

Enterprise can point that vault at the store security already runs: HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault. Model routing uses the same credential-ref split for BYOM provider keys.

A credential ref is a connection id. Workflows name that id. They do not name the secret.

Confirm health#

Nuroen tests the connection and reports health before a graph may reference it. A down or unauthenticated dependency is not “ready.” Live status shows on the canvas so you do not bind a broken ref and find out at publish.

Test before production. Health is a gate, not a badge. If the test fails, fix the credential. Do not disable governance to ship anyway.

Bind#

Drag connector nodes onto the agent graph. Workflows reference secure connection ids — not secrets — so every environment from staging to production uses the same governed integration.

Bind is a graph edit. It does not copy the credential into the node. The node points at the ref you created in Connect.

Credential refs, not secrets#

A connector node is a typed graph node, the same family as triggers, skills, conditions, and outputs. The edge into that node must type-check. A type-mismatched edge hard-blocks production the same way a missing secret does.

Conversational authoring can attach a ref as a schema-constrained JSON diff. It cannot invent a connector, paste a key, or show an unvalidated graph as ready to run.

See First agent for where bind sits on Define → Confirm → Validate → Build. Validate still hard-blocks an unauthenticated connector and a missing secret.

Same connection, every environment#

Connect once. Bind anywhere. Staging and production graphs reference the same connection id so you do not maintain a second secret per environment on the canvas. Promote the graph; the ref stays the governed integration.

If an environment must use a different credential, create a second connection in Connect and bind that ref. Do not fork the secret into a node property.

Deploy is blocked until every connector on the graph is authenticated. Missing credentials are a publish blocker, not a runtime surprise. Simulation surfaces that blocker before you promote.

Act#

Agents query databases, create tickets, update CRM records, and send notifications using vault-backed credentials — with audit trails, success metrics, and runtime policy enforcement.

Act is live work in production systems, not a simulated chat reply. Read data, update records, create tickets, send notifications, trigger workflows, and run the operations the bound connectors allow. The agent uses scoped credentials and approved connectors only.

Live enterprise actions#

The published graph pins an immutable version. A run executes that version with the credential refs bound at publish. If you rotate a secret in the vault, the ref stays; the new material is what the runtime fetches.

Clearing simulation does not turn Act into an ungated loop. After publish, every action still passes the runtime envelope.

Runtime policy still applies#

L2 (policy-gated) is the production default. Scope, confidence, policy, approval, and budget still run on the execution path. One fail stops the action and hands humans the context. High-impact writes pause for a named approver. An approval gate with no assignee hard-blocks.

Credentials used at Act time are scoped to what this task needs. The agent does not receive the whole vault. Kill-switch, blast-radius caps, and budget checks sit on the same envelope as governance.

Every policy check, approval, and connector call writes to the SHA-256 hash-chained provenance ledger. Export that trail for SIEM and GRC from Platform APIs — you do not reconstruct chat logs after an incident.

See Platform connectors for the live catalog, then build your first agent or install from the catalog. Keep governance on — you do not turn it off to finish an integration.

Governance operates continuously — before, during, and after execution. Set the rules once. Every agent action is policy-checked, supervised when needed, and recorded in a tamper-evident audit trail.

Policies are enforced at runtime, not only in the interface. Controls are not optional UI toggles. Every deployment is validated, every execution is recorded, and agents never operate outside organizational policy.

Restraint is the foundation, not a toggle. Every agent ships bounded, auditable, and cost-controlled from its first save — whether you build from a job description or install from the catalog. You do not turn governance off to finish a build. Governance is enforced at runtime — safe by default, with approval gates, autonomy levels, budget limits, and a hash-chained provenance record for every run.

On by default#

Capability rises from a safe floor, not an open ceiling. Finance, security, and audit get their veto by construction — so regulated teams deploy instead of stalling in review.

Drafts arrive least-privilege: required grounding, a capped budget, and an inherited policy envelope. You raise autonomy only where the org has justified it. The people closest to the work can still build; the platform keeps the restraint.

Policy#

Set org-wide guardrails once: autonomy ladder, permission matrix, and approval thresholds. Every agent inherits the same policy envelope without per-workflow drift.

Author policy once and attach it to any agent or team. One change propagates everywhere — the same rules at build time and in production. Update a single rule, such as blocking data egress, and every bound agent re-governs on the next run, with version-level provenance for auditors. Rules live in the same pipeline that executes the work, not in a spreadsheet someone has to remember to update.

Autonomy ladder#

The ladder is L0–L4, from suggest-only behavior to fully governed execution. L2 (policy-gated) is the production default. Per-agent approval gates, budget caps, and a kill-switch sit on the same envelope.

You control how autonomous every agent can be while keeping every action inside organizational boundaries. High-impact work still pauses for sign-off. A policy change takes effect on the next run.

Users and access#

Manage identities, permissions, and credentials through enterprise authentication and role-based access control. Control exactly who can build, approve, execute, and monitor agents.

SSO and RBAC sit on the same envelope as runtime policy. Connector secrets stay in the tenant vault — the canvas stores credential refs, not secrets.

Every action passes the gates#

Scope, confidence, policy, approval, budget — nothing runs until every gate clears. One fail stops the action and hands humans the full context.

The engine sits on the execution path itself. Studio, code, schedules, and external systems all hit the same gates. No bypass. No silent failures. Scope, confidence, policy, approval, budget — nothing runs until every gate clears. One fail stops the action and hands humans the full context.

Only after every prior gate clears does the governed action run — with scoped credentials, approved connectors, and the permissions this task requires. Execution is sandboxed to the autonomy level granted.

Rates and plan names live on Pricing, not in this guide. Credits are the billing unit for AI usage. Each model call deducts credits based on a rate table — checked before execution, not after. You always know the cost ceiling before a run starts.

Gate#

Every high-impact action passes policy evaluation, risk classification, and blast-radius checks. Execution pauses automatically when confidence or scope falls outside bounds.

Configure approval thresholds, confidence floors, spend caps, blast-radius limits, and emergency kill switches — the behavioral contract every agent must honor before a single action runs. Schedule windows, model allowlists, and execution gates apply in real time.

Supervise#

High-risk proposals land in a unified review queue. Approvers see context, risk tier, and rollback options — approve, deny, or let policy decide with a 24h undo window.

High-impact actions pause for sign-off with full context, not a courtesy prompt. Approve, reject, or modify before anything proceeds. Every decision is logged for audit across chat, schedules, and orchestrated runs.

Critical decisions stay under human control whenever organizational policy requires approval. Approve before impact — not after damage.

Prove#

Every policy check, approval, and run writes to a tamper-evident provenance chain. Each record links to the prior entry so finance, security, and legal teams can verify the chain was not altered after the fact.

This is not a best-effort log file. Compliance teams export verifiable timelines without reconstructing chat logs after an incident. Stage-by-stage decisions, approvals, spend events, and outcomes land in the same governed record.

The ledger is a SHA-256 hash chain. Platform APIs describe provenance export for SIEM and GRC pipelines — an overview, not a REST catalog.

# Runtime envelope — conceptual, not a public API path
autonomy: L2
gates: [scope, confidence, policy, approval, budget]
supervise: [review-queue, 24h-undo]
ledger: SHA-256 hash chain

Govern once, enforce everywhere#

The four stages are one envelope. Marketplace installs and from-scratch builds use the same gates. Model routing honors the same residency pin and budget ceiling — builders do not pick a model on each call.

Preview vs the product#

The homepage Try ICARUS lab shows how ICARUS interprets intent, selects skills, wires connectors, and inserts governance gates — before anything executes. It is preview-only. It is not a tenant, it does not meter your credits, and it does not replace runtime policy in the product.

See Platform Governance for the live capability. Next: build your first governed agent, connect a system, or export provenance from Platform APIs.