# BRAIAN by ÆTERION — full content > BRAIAN by ÆTERION is the AI operating system built by AETERION. It runs core business processes as autonomous workflows across finance, legal, risk, HR, sales, marketing, IT and customer care — each executed by a specialised agent under a versioned policy. Every decision is logged, every escalation surfaces to a human, and data residency stays within Switzerland and the EU. Every English page of https://aeterion.tech as a single markdown document. Generated from the site source. --- # The platform that runs your processes under policy > The BRAIAN platform has four layers. A control plane holds policies and permissions, an orchestration runtime executes process steps, an evaluation layer scores agent output before release, and observability records traces, cost and outcomes. The layers share one data model, so a policy change takes effect everywhere at once. Source: https://aeterion.tech/en/platform BRAIAN turns business processes into governed software: one control plane, one runtime, one record of every decision taken. ## Four layers, one runtime Each layer is usable on its own and stronger together. Companies usually start with the control plane over existing automation, then move execution into the runtime. ### Control plane Policies, permissions, secrets and environments, versioned and enforced at runtime. ### Orchestration Process definitions, agent routing, retries, escalation and human approval steps. ### Evaluation Test suites, scoring and release gates that block regressions before production. ### Observability Traces, cost and outcomes for every run, written to an append-only audit log. ### Carol The conversational layer: ask a running process a question by voice or text, under the same permissions. ## The full inventory ### Platform features Every capability in one checklist: what it does, whether it is available or in development, and where to read more. ## What does the platform replace? - Scripts and notebooks that call models directly with no permission model. - Automation spread across tools where no single team can answer who approved what. - Prompt changes shipped without regression testing or rollback. - Manual evidence collection at audit time, reconstructed from logs after the fact. ## How does a process run? - **1. Define** — A process is modelled as steps with owners, inputs, expected outputs and the systems it may touch. - **2. Authorise** — The control plane resolves which agent, service or person may execute each step, and under which limits. - **3. Execute** — The runtime runs the step, retries on failure, and escalates to a human when confidence or policy requires it. - **4. Record** — Inputs, outputs, cost, model version and approvals are written to an immutable trace. ## FAQ ### Is BRAIAN a consulting service? No. BRAIAN is a software product, licensed per environment. Onboarding support exists, but the platform is what you buy. ### Do we have to move our data into BRAIAN? No. BRAIAN reads and writes through connectors to your existing systems. It stores process metadata, traces and policies, not a copy of your operational database. ### Can we start with a single process? Yes. A first process usually goes live in weeks on one connector, then the same control plane covers further processes without new infrastructure. ## See the platform on your own process We run a working session on one of your processes and show the control plane, runtime and audit trail against it. --- # Control plane > The control plane is the policy layer of BRAIAN. It holds identities, roles, connector permissions, data boundaries, spending limits and approval rules as versioned configuration. The runtime asks the control plane before every step, so an agent can only do what policy currently allows, and every change is attributable to a person and a version. Source: https://aeterion.tech/en/platform/processes One place to declare who may act, on which systems, with which data and within which limits — enforced on every run. ## What does a policy cover? - Which agents and services may run a step, and on whose behalf. - Which systems and record types a step may read or write. - Limits per run and per period: cost, volume, blast radius. - When a human approval is mandatory before the step continues. - Which data may leave the environment, and which must stay inside it. ## Versioned, not improvised Policies are stored as configuration with authorship and history. You can diff two versions, promote a policy from staging to production, and roll back a change without touching process code. ## Environments and secrets - **Environments** — Development, staging and production hold separate credentials and separate limits, with promotion as an explicit step. - **Secrets** — Connector credentials are held in the control plane and never exposed to agent prompts or process definitions. - **Identity** — Users and service accounts authenticate through your identity provider; roles map to policy, not to individual scripts. ## FAQ ### Does a policy change require a deployment? No. Policies are configuration. A new version takes effect on the next step the runtime authorises. ### Can two business units have different rules? Yes. Policies are scoped, so units, regions or subsidiaries can hold different limits under one platform. ## Put your rules in one place We map your current permissions and show them as enforceable policy in BRAIAN. --- # Agent orchestration > Orchestration in BRAIAN executes a process definition step by step. Each step names its owner, its inputs and its success condition. The runtime handles routing between agents, tool calls to connected systems, retries on transient failure and escalation to a human when confidence is low. State survives restarts, so long processes never depend on a live script. Source: https://aeterion.tech/en/platform/agents Model a process once; the runtime routes every step to the agent, service or person that owns it, with retries and escalation built in. ## What does the runtime handle for you? - Durable state: a process that waits three days for an approval resumes where it stopped. - Retries and back-off on transient errors, with a bounded number of attempts. - Escalation paths: low confidence, policy conflict or missing data go to a named owner. - Concurrency limits so a batch never floods a downstream system. - Idempotency on writes, so a retry does not duplicate an order or a ticket. ## Humans are part of the process Approval steps are first-class. A reviewer sees the step, the inputs, the proposed action and the policy that applies, then approves, edits or rejects. The decision is recorded with the run, not in a side channel. ## Process definitions - **Declarative** — Steps, owners and conditions are configuration, readable by the people accountable for the process. - **Versioned** — A running process keeps the version it started on; new runs pick up the new version. - **Portable** — The same definition runs in staging against test systems and in production against live ones. ## FAQ ### What happens when a model is unavailable? The step retries under policy, then falls back to the configured alternative or to a human owner. The run is never left in an undefined state. ### Can we keep existing automation? Yes. Existing jobs and RPA tasks can be invoked as steps, so orchestration wraps what already works instead of replacing it on day one. ## Run one process end to end Bring a process with a real approval step and we will model it live. --- # Evaluation > Evaluation in BRAIAN turns agent quality into a measurement. Test suites hold representative cases with expected outcomes; every candidate change — a new prompt, model or tool — is scored against them. Release gates block a change that regresses, and the same checks continue to sample production runs, so quality drift is visible before a business owner reports it. Source: https://aeterion.tech/en/platform/policies Score agent output against expected results before release, and keep scoring it while the process runs in production. ## What gets measured? - Task success against a labelled expected outcome. - Faithfulness to source documents, for retrieval-based steps. - Policy compliance: did the run stay inside its permissions and limits. - Cost and latency per run, per process and per model version. - Human override rate — how often a reviewer changes the proposed action. ## Release gates A change reaches production only when the suite passes the thresholds you set. The comparison is version to version, so you can see exactly which cases improved and which broke. ## From incident to test case - **Capture** — A wrong output in production can be promoted into the test suite with one action, together with its inputs. - **Fix** — The candidate change is scored against the whole suite, not just the failing case. - **Prove** — The release record shows which version fixed the case and who approved the promotion. ## FAQ ### Do we need labelled data to start? A small set is enough. Most teams start with twenty to fifty real cases per process and grow the suite from production incidents. ### Who owns the thresholds? The process owner. Thresholds are policy, set per process and versioned like every other rule. ## Measure before you deploy We build a first evaluation suite on one of your processes during the demo. --- # Observability > Observability in BRAIAN records what actually happened. Each run produces a structured trace of steps, tool calls, data touched, model and prompt versions, cost, latency, human approvals and the final outcome. Traces are retained under your policy and can be searched, exported and attached to an audit request without reconstructing anything from application logs. Source: https://aeterion.tech/en/platform/audit-log Every run leaves a trace: inputs, tool calls, model versions, cost, approvals and outcome, queryable long after the process finished. ## What does a trace contain? - The process and version that ran, and who or what triggered it. - Each step: inputs, outputs, duration, cost and the policy that authorised it. - Every external call: system, operation, record identifiers, success or failure. - Human interventions: who approved, changed or rejected, and when. - The final outcome and any downstream effect the run produced. ## Operations and finance in one view The same data answers two different questions: whether the process is healthy, and what it costs. Cost is attributed per process, per team and per model, so budget conversations use measured numbers. ## How long is data retained, and how do you export it? - **Retention** — Trace retention is a policy setting, aligned to your records-management rules. - **Export** — Traces export to your SIEM or data warehouse for long-term analysis. - **Access** — Who may read traces, and which fields they see, is governed by the control plane. ## FAQ ### Are traces suitable as audit evidence? They are designed for it: append-only, attributable and complete for the run, including the policy version in force at the time. ### Can we alert on this data? Yes. Thresholds on failure rate, override rate, latency or cost raise alerts to your existing on-call channels. ## See what your automation actually does We show a real trace end to end, from trigger to recorded outcome. --- # Carol > Carol is the conversational layer of BRAIAN. Employees use voice or text to navigate the processes they work on — across business units, within their own permissions. Carol adapts to each person: their role, their systems, their vocabulary. Every question and every action is logged under the same policies that govern production workflows. Source: https://aeterion.tech/en/platform/carol Part of: BRAIAN ## What can you ask? Carol answers from the systems a process already runs on, and names where each part of the answer comes from. ### Where are we with this supplier onboarding? Step 4 of 6, awaiting approval since Tuesday. Compliance screening passed; the bank details check is blocked on a missing certificate. Answer drawn from: Procurement, Compliance, Finance ### Why was this invoice escalated? FinAgent matched the invoice to a purchase order with a CHF 12,400 variance, above the CHF 10,000 approval threshold in policy v4.2, so it routed to the cost centre owner. Answer drawn from: Finance, Audit log ### What does this contract clause commit us to? Clause 8.3 sets a 30-day cure period and auto-renewal unless cancelled 90 days before term. LegalAgent flagged it against the standard playbook. Answer drawn from: Legal, Procurement ## How does it work? ### Organisational knowledge layer Carol reads the same process definitions, policies, connectors and audit records the runtime uses. There is no separate knowledge base to maintain and no copy of your operational data to keep in sync. ### Permission-aware retrieval Every retrieval runs under the asking person's identity. Records outside their permissions are not summarised, not cited and not counted — the answer is built only from what that person could already open themselves. ### From conversation to governed process When a question turns into an action — approve, escalate, re-run a step — Carol hands it to the runtime. The action executes under its versioned policy and lands in the audit log like any other run. ## Voice and text The same layer, the same permissions, two ways in. - **Text** — In the BRAIAN console, and in Microsoft Teams and Slack through the existing connectors. - **Voice** — Speech-to-text in the console and on mobile, for hands-free status checks and approvals within threshold. - **Languages** — English, Italian and German, including mixed-language questions about the same process. - **Context** — A conversation keeps the process it is about, so follow-up questions do not need to repeat identifiers. ## Personalisation and boundaries Carol personalises to each employee; it does not model them. The distinction is a design constraint, not a setting. ### What Carol adapts to - The role and permissions on the account asking the question. - The systems and processes that role actually works on. - The vocabulary of the business unit — its terms for documents, steps and thresholds. - Preferred language, level of detail and output format. ### What Carol does not do - It does not build a profile of an employee's behaviour, productivity or performance. - It does not answer on behalf of a person or act with anyone else's identity. - It does not surface records outside the asking person's permissions, including in summaries. - It does not execute an action that exceeds the policy in force for that process. - Conversations are not used to train models; they are logged as records, retained under the same policy as process traces. ## See Carol answer on your own process We connect one process in a working session and ask it the questions your teams ask today. --- # How BRAIAN is deployed > BRAIAN is deployed as a managed environment in Switzerland or the European Union, or inside your own cloud tenancy. The runtime holds process state, policies and traces. Connectors reach your systems over controlled network paths. Model providers are called through a gateway that enforces policy, redaction and cost limits on every request. Source: https://aeterion.tech/en/architecture A governed runtime that sits between your systems and the models you use, with data residency and network boundaries you decide. ## Deployment options ### Managed (CH) Hosted by ÆTERION in Switzerland. Fastest to start, Swiss data residency, operated to a published service level. ### Managed (EU) Hosted in the European Union for organisations with EU-only residency requirements. ### Your cloud Deployed into your own tenancy when internal policy requires the runtime to sit inside your perimeter. ## Data boundaries - Operational data stays in your systems; BRAIAN holds process metadata, policies and traces. - Redaction rules strip identifiers before a request leaves for a model provider. - Model routing is policy: a process can be restricted to providers in a given jurisdiction. - Encryption in transit and at rest, with key management aligned to your standard. ## Integration surface - **Connectors** — Governed adapters for ERP, CRM, ticketing, storage and databases, each with its own permissions. - **API** — A documented HTTP API to trigger processes, read state and pull traces. - **Events** — Webhooks and message-queue triggers so processes start from events you already emit. - **Identity** — SSO through your identity provider, with roles mapped to control-plane policy. ## FAQ ### Which models can BRAIAN use? Commercial and open-weight models through the gateway, selected per step by policy. Model choice is configuration, not a rewrite. ### Can we run without any external model provider? Yes, where self-hosted models are available in your environment; the gateway then routes only to internal endpoints. ## Review the architecture with your team We walk your architects through deployment, data flows and network boundaries. --- # BRAIAN works inside the systems you already run. > BRAIAN connects to enterprise systems through authenticated, scoped integrations. Agents read and write in the systems of record your processes already use — ERP, CRM, data platforms, document management and identity providers. Every connection carries explicit permissions, and every action an agent takes through it is logged. Source: https://aeterion.tech/en/integrations ## How do connections work? ### Scoped by design Each integration is granted the minimum permissions its processes require. Scopes are defined per agent, not per system: FinAgent can read invoices without being able to modify vendor master data. ### Authenticated, not shared Connections use the system's own authentication — OAuth, service principals or API credentials held in a secrets vault. BRAIAN never stores end-user passwords. ### Logged at the boundary Every read and write crossing an integration is recorded in the audit log with the agent, the policy in force and the timestamp. ## Systems AETERION connects to - **SAP S/4HANA** (ERP, Available) — Read and post financial documents under policy. — https://aeterion.tech/en/integrations/sap-s4hana - **Microsoft Dynamics 365** (ERP, Available) — Operate across finance and operations modules. — https://aeterion.tech/en/integrations/microsoft-dynamics-365 - **Abacus** (ERP, Available) — Swiss accounting and payroll, natively connected. — https://aeterion.tech/en/integrations/abacus - **Odoo** (ERP, Available) — Full-stack ERP for mid-market operations. — https://aeterion.tech/en/integrations/odoo - **Salesforce** (CRM, Available) — Read pipeline, act on opportunities and accounts. — https://aeterion.tech/en/integrations/salesforce - **HubSpot** (CRM, Available) — Connect marketing and sales workflows. — https://aeterion.tech/en/integrations/hubspot - **Databricks** (Data Platform, Available) — Query the data layer processes depend on. — https://aeterion.tech/en/integrations/databricks - **Snowflake** (Data Platform, Available) — Read analytical data without copying it. — https://aeterion.tech/en/integrations/snowflake - **ServiceNow** (ITSM, Available) — Run IT and service processes end to end. — https://aeterion.tech/en/integrations/servicenow - **Jira** (ITSM, Available) — Operate on issues and workflows. — https://aeterion.tech/en/integrations/jira - **Microsoft SharePoint** (Document Management, Available) — Read contracts and documents where they live. — https://aeterion.tech/en/integrations/microsoft-sharepoint - **Google Drive** (Document Management, Available) — Access documents under user-level permissions. — https://aeterion.tech/en/integrations/google-drive - **Microsoft Teams** (Communication, Available) — Escalations and approvals where people already work. — https://aeterion.tech/en/integrations/microsoft-teams - **Slack** (Communication, Available) — Approvals and notifications in channel. — https://aeterion.tech/en/integrations/slack - **Microsoft Entra ID** (Identity, Available) — The permission model BRAIAN runs on. — https://aeterion.tech/en/integrations/microsoft-entra-id - **Okta** (Identity, Available) — Identity and access as the basis for agent permissions. — https://aeterion.tech/en/integrations/okta ## Don't see your system? BRAIAN connects to any system with an API. If the system your process runs on is not listed, tell us which one it is. --- # SAP S/4HANA integration > BRAIAN connects to SAP S/4HANA through OData / SAP API Business Hub, service user. Agents can invoice retrieval and matching, purchase order lookup and vendor master read. Every action is scoped by the permissions granted to the integration and executed under a versioned policy. Each one is recorded in the audit log with the agent, timestamp and record touched. Source: https://aeterion.tech/en/integrations/sap-s4hana Category: ERP FinAgent and RiskAgent work on the financial and purchasing documents held in SAP S/4HANA: invoices, purchase orders and vendor master data. Postings are scoped by company code and executed only where the policy in force allows a write. ## What can BRAIAN do? | Capability | Agent | Read or write | | --- | --- | --- | | Invoice retrieval and matching | FinAgent | Read | | Purchase order lookup | FinAgent | Read | | Vendor master read | RiskAgent | Read | | Journal entry posting | FinAgent | Write | | Payment proposal review | FinAgent | Read | ## How does it connect? - **Connection method** — OData / SAP API Business Hub, service user - **Credential** — A dedicated SAP service user with an OData authorisation profile. No named end-user account is used. Credentials are held in an encrypted secrets store. BRAIAN never stores end-user passwords. ## Which permissions are required? - **read FI-AP** — Accounts payable documents: invoices, credit notes and their clearing status. - **read MM-PUR** — Purchasing documents required to match an invoice to its order and goods receipt. - **write FI (scoped by company code)** — Posting rights limited to the company codes the configured processes cover. Permissions are requested at the minimum scope the configured processes require. Unused scopes are not granted. ## Which processes use it? - Invoice reconciliation - Expense audit - Supplier onboarding ## How do you revoke access? Access is revoked in SAP S/4HANA itself — by disabling the credential or removing the granted scopes — or in BRAIAN by disconnecting the integration. Processes already running stop at their next call to SAP S/4HANA and are held for review rather than completed with partial data; the interruption and the state of each process are recorded in the audit log. ## FAQ ### Does BRAIAN store data from SAP S/4HANA? BRAIAN reads what a process needs, when it needs it. Records retrieved from SAP S/4HANA are held only for the duration of the process and in the audit trail of the actions taken; SAP S/4HANA remains the system of record. ### What happens if the connection fails mid-process? The process stops at the failed step and is held for review. Nothing is written twice: completed writes stay recorded in the audit log and the remaining steps resume only once the connection is restored. ### Can permissions be scoped per agent? Yes. Scopes are defined per agent, not per system, so one agent can read while another cannot, on the same connection to SAP S/4HANA. --- # Microsoft Dynamics 365 integration > BRAIAN connects to Microsoft Dynamics 365 through Dataverse Web API, OAuth service principal. Agents can invoice and vendor read, purchase requisition creation and approval workflow trigger. Every action is scoped by the permissions granted to the integration and executed under a versioned policy. Each one is recorded in the audit log with the agent, timestamp and record touched. Source: https://aeterion.tech/en/integrations/microsoft-dynamics-365 Category: ERP Agents read vendor, invoice and customer records in Dataverse and trigger the approval workflows already configured in Dynamics 365. Each agent connects under its own security role, so its reach is defined in the system's own permission model. ## What can BRAIAN do? | Capability | Agent | Read or write | | --- | --- | --- | | Invoice and vendor read | FinAgent | Read | | Purchase requisition creation | FinAgent | Write | | Approval workflow trigger | RiskAgent | Write | | Customer record read | SalesAgent | Read | ## How does it connect? - **Connection method** — Dataverse Web API, OAuth service principal - **Credential** — An Entra ID service principal with a client secret or certificate, issued per environment. Credentials are held in an encrypted secrets store. BRAIAN never stores end-user passwords. ## Which permissions are required? - **scoped security roles per agent** — Each agent is mapped to a Dynamics security role limited to the tables its processes touch. Permissions are requested at the minimum scope the configured processes require. Unused scopes are not granted. ## Which processes use it? - Invoice reconciliation - Supplier onboarding - Offering ## How do you revoke access? Access is revoked in Microsoft Dynamics 365 itself — by disabling the credential or removing the granted scopes — or in BRAIAN by disconnecting the integration. Processes already running stop at their next call to Microsoft Dynamics 365 and are held for review rather than completed with partial data; the interruption and the state of each process are recorded in the audit log. ## FAQ ### Does BRAIAN store data from Microsoft Dynamics 365? BRAIAN reads what a process needs, when it needs it. Records retrieved from Microsoft Dynamics 365 are held only for the duration of the process and in the audit trail of the actions taken; Microsoft Dynamics 365 remains the system of record. ### What happens if the connection fails mid-process? The process stops at the failed step and is held for review. Nothing is written twice: completed writes stay recorded in the audit log and the remaining steps resume only once the connection is restored. ### Can permissions be scoped per agent? Yes. Scopes are defined per agent, not per system, so one agent can read while another cannot, on the same connection to Microsoft Dynamics 365. --- # Abacus integration > BRAIAN connects to Abacus through AbaConnect / REST API. Agents can creditor invoice read, booking proposal and cost centre lookup. Every action is scoped by the permissions granted to the integration and executed under a versioned policy. Each one is recorded in the audit log with the agent, timestamp and record touched. Source: https://aeterion.tech/en/integrations/abacus Category: ERP FinAgent reads creditor invoices and prepares booking proposals against the correct cost centre; HRAgent reads the payroll and personnel documents it needs for policy checks. The connection is read-only by default and write access is enabled per mandate. ## What can BRAIAN do? | Capability | Agent | Read or write | | --- | --- | --- | | Creditor invoice read | FinAgent | Read | | Booking proposal | FinAgent | Write | | Cost centre lookup | FinAgent | Read | | Document archive access | HRAgent | Read | ## How does it connect? - **Connection method** — AbaConnect / REST API - **Credential** — An Abacus API user issued per mandate, with the mandate number bound to the connection. Credentials are held in an encrypted secrets store. BRAIAN never stores end-user passwords. ## Which permissions are required? - **read-only by default** — Every new connection starts without write rights. - **write scoped per mandate** — Booking rights are granted only for the mandates whose processes are configured. Permissions are requested at the minimum scope the configured processes require. Unused scopes are not granted. ## Which processes use it? - Invoice reconciliation - Expense audit - Policy compliance Widely deployed across Swiss SMEs and mid-market companies. ## How do you revoke access? Access is revoked in Abacus itself — by disabling the credential or removing the granted scopes — or in BRAIAN by disconnecting the integration. Processes already running stop at their next call to Abacus and are held for review rather than completed with partial data; the interruption and the state of each process are recorded in the audit log. ## FAQ ### Does BRAIAN store data from Abacus? BRAIAN reads what a process needs, when it needs it. Records retrieved from Abacus are held only for the duration of the process and in the audit trail of the actions taken; Abacus remains the system of record. ### What happens if the connection fails mid-process? The process stops at the failed step and is held for review. Nothing is written twice: completed writes stay recorded in the audit log and the remaining steps resume only once the connection is restored. ### Can permissions be scoped per agent? Yes. Scopes are defined per agent, not per system, so one agent can read while another cannot, on the same connection to Abacus. --- # Odoo integration > BRAIAN connects to Odoo through XML-RPC / JSON-RPC, dedicated API user. Agents can invoice and bill read, vendor management and purchase order lifecycle. Every action is scoped by the permissions granted to the integration and executed under a versioned policy. Each one is recorded in the audit log with the agent, timestamp and record touched. Source: https://aeterion.tech/en/integrations/odoo Category: ERP Agents follow the purchase order lifecycle in Odoo, read bills and vendor records and check inventory positions. The connection uses a dedicated API user whose access rights are configured in Odoo itself. ## What can BRAIAN do? | Capability | Agent | Read or write | | --- | --- | --- | | Invoice and bill read | FinAgent | Read | | Vendor management | RiskAgent | Read and write | | Purchase order lifecycle | FinAgent | Read and write | | Inventory lookup | FinAgent | Read | ## How does it connect? - **Connection method** — XML-RPC / JSON-RPC, dedicated API user - **Credential** — A dedicated Odoo API user with an API key, restricted to the models its processes use. Credentials are held in an encrypted secrets store. BRAIAN never stores end-user passwords. ## Which permissions are required? - **account.move, purchase.order, res.partner, stock.quant** — Model-level access rights, granted only for the records the configured processes read or write. Permissions are requested at the minimum scope the configured processes require. Unused scopes are not granted. ## Which processes use it? - Invoice reconciliation - Supplier onboarding - Third-party due diligence ## How do you revoke access? Access is revoked in Odoo itself — by disabling the credential or removing the granted scopes — or in BRAIAN by disconnecting the integration. Processes already running stop at their next call to Odoo and are held for review rather than completed with partial data; the interruption and the state of each process are recorded in the audit log. ## FAQ ### Does BRAIAN store data from Odoo? BRAIAN reads what a process needs, when it needs it. Records retrieved from Odoo are held only for the duration of the process and in the audit trail of the actions taken; Odoo remains the system of record. ### What happens if the connection fails mid-process? The process stops at the failed step and is held for review. Nothing is written twice: completed writes stay recorded in the audit log and the remaining steps resume only once the connection is restored. ### Can permissions be scoped per agent? Yes. Scopes are defined per agent, not per system, so one agent can read while another cannot, on the same connection to Odoo. --- # Salesforce integration > BRAIAN connects to Salesforce through REST API, connected app with OAuth. Agents can account and opportunity read, activity logging and contract record lookup. Every action is scoped by the permissions granted to the integration and executed under a versioned policy. Each one is recorded in the audit log with the agent, timestamp and record touched. Source: https://aeterion.tech/en/integrations/salesforce Category: CRM SalesAgent reads accounts, opportunities and activity history and writes back the actions it performs; LegalAgent reads the contract records attached to an account. Field-level security configured in Salesforce is respected as it stands. ## What can BRAIAN do? | Capability | Agent | Read or write | | --- | --- | --- | | Account and opportunity read | SalesAgent | Read | | Activity logging | SalesAgent | Write | | Contract record lookup | LegalAgent | Read | | Data quality checks | SalesAgent | Read | ## How does it connect? - **Connection method** — REST API, connected app with OAuth - **Credential** — A Salesforce connected app using the OAuth client credentials flow, bound to an integration user. Credentials are held in an encrypted secrets store. BRAIAN never stores end-user passwords. ## Which permissions are required? - **profile-scoped object access** — The integration user's profile determines which objects each agent can reach. - **field-level security respected** — Fields hidden from the profile are never returned to an agent. Permissions are requested at the minimum scope the configured processes require. Unused scopes are not granted. ## Which processes use it? - Offering - Confirmation Order - Contract analysis ## How do you revoke access? Access is revoked in Salesforce itself — by disabling the credential or removing the granted scopes — or in BRAIAN by disconnecting the integration. Processes already running stop at their next call to Salesforce and are held for review rather than completed with partial data; the interruption and the state of each process are recorded in the audit log. ## FAQ ### Does BRAIAN store data from Salesforce? BRAIAN reads what a process needs, when it needs it. Records retrieved from Salesforce are held only for the duration of the process and in the audit trail of the actions taken; Salesforce remains the system of record. ### What happens if the connection fails mid-process? The process stops at the failed step and is held for review. Nothing is written twice: completed writes stay recorded in the audit log and the remaining steps resume only once the connection is restored. ### Can permissions be scoped per agent? Yes. Scopes are defined per agent, not per system, so one agent can read while another cannot, on the same connection to Salesforce. --- # HubSpot integration > BRAIAN connects to HubSpot through Private app token. Agents can contact and deal read, lifecycle stage updates and campaign data read. Every action is scoped by the permissions granted to the integration and executed under a versioned policy. Each one is recorded in the audit log with the agent, timestamp and record touched. Source: https://aeterion.tech/en/integrations/hubspot Category: CRM SalesAgent and MaAgent read contacts, deals and campaign data, update lifecycle stages and log the activities they perform. The connection uses a private app token whose scopes are set per portal. ## What can BRAIAN do? | Capability | Agent | Read or write | | --- | --- | --- | | Contact and deal read | SalesAgent | Read | | Lifecycle stage updates | MaAgent | Write | | Campaign data read | MaAgent | Read | | Activity logging | SalesAgent | Write | ## How does it connect? - **Connection method** — Private app token - **Credential** — A HubSpot private app token, created in the customer portal and revocable there at any time. Credentials are held in an encrypted secrets store. BRAIAN never stores end-user passwords. ## Which permissions are required? - **crm.objects.contacts / crm.objects.deals** — Read and write on the CRM objects the configured processes use. - **marketing.campaigns.read** — Campaign performance data, read only. Permissions are requested at the minimum scope the configured processes require. Unused scopes are not granted. ## Which processes use it? - Inbound process - Outbound process - Offering ## How do you revoke access? Access is revoked in HubSpot itself — by disabling the credential or removing the granted scopes — or in BRAIAN by disconnecting the integration. Processes already running stop at their next call to HubSpot and are held for review rather than completed with partial data; the interruption and the state of each process are recorded in the audit log. ## FAQ ### Does BRAIAN store data from HubSpot? BRAIAN reads what a process needs, when it needs it. Records retrieved from HubSpot are held only for the duration of the process and in the audit trail of the actions taken; HubSpot remains the system of record. ### What happens if the connection fails mid-process? The process stops at the failed step and is held for review. Nothing is written twice: completed writes stay recorded in the audit log and the remaining steps resume only once the connection is restored. ### Can permissions be scoped per agent? Yes. Scopes are defined per agent, not per system, so one agent can read while another cannot, on the same connection to HubSpot. --- # Databricks integration > BRAIAN connects to Databricks through SQL Warehouse endpoint, service principal. Agents can sql warehouse queries, unity catalog lineage read and table access under catalog permissions. Every action is scoped by the permissions granted to the integration and executed under a versioned policy. Each one is recorded in the audit log with the agent, timestamp and record touched. Source: https://aeterion.tech/en/integrations/databricks Category: Data Platform Agents query the SQL warehouse for the figures a process needs and read lineage from Unity Catalog. Table access is decided by Unity Catalog grants, which are enforced natively rather than reimplemented. ## What can BRAIAN do? | Capability | Agent | Read or write | | --- | --- | --- | | SQL warehouse queries | All agents | Read | | Unity Catalog lineage read | All agents | Read | | Table access under catalog permissions | All agents | Read | ## How does it connect? - **Connection method** — SQL Warehouse endpoint, service principal - **Credential** — A Databricks service principal with an OAuth token, scoped to one workspace. Credentials are held in an encrypted secrets store. BRAIAN never stores end-user passwords. ## Which permissions are required? - **Unity Catalog grants** — Catalog, schema and table grants are enforced by Databricks itself; BRAIAN adds no parallel access path. Permissions are requested at the minimum scope the configured processes require. Unused scopes are not granted. ## Which processes use it? - Invoice reconciliation - Expense audit - Data access review ## How do you revoke access? Access is revoked in Databricks itself — by disabling the credential or removing the granted scopes — or in BRAIAN by disconnecting the integration. Processes already running stop at their next call to Databricks and are held for review rather than completed with partial data; the interruption and the state of each process are recorded in the audit log. ## FAQ ### Does BRAIAN store data from Databricks? BRAIAN reads what a process needs, when it needs it. Records retrieved from Databricks are held only for the duration of the process and in the audit trail of the actions taken; Databricks remains the system of record. ### What happens if the connection fails mid-process? The process stops at the failed step and is held for review. Nothing is written twice: completed writes stay recorded in the audit log and the remaining steps resume only once the connection is restored. ### Can permissions be scoped per agent? Yes. Scopes are defined per agent, not per system, so one agent can read while another cannot, on the same connection to Databricks. --- # Snowflake integration > BRAIAN connects to Snowflake through Snowflake SQL API, key-pair authentication. Agents can warehouse queries, role-scoped table access and result set retrieval. Every action is scoped by the permissions granted to the integration and executed under a versioned policy. Each one is recorded in the audit log with the agent, timestamp and record touched. Source: https://aeterion.tech/en/integrations/snowflake Category: Data Platform Agents run queries against Snowflake under a dedicated role and receive only the result set a process needs. No bulk extraction takes place: the data stays where it is governed. ## What can BRAIAN do? | Capability | Agent | Read or write | | --- | --- | --- | | Warehouse queries | All agents | Read | | Role-scoped table access | All agents | Read | | Result set retrieval | All agents | Read | ## How does it connect? - **Connection method** — Snowflake SQL API, key-pair authentication - **Credential** — A Snowflake service user authenticated with an RSA key pair; the private key is held in the secrets store. Credentials are held in an encrypted secrets store. BRAIAN never stores end-user passwords. ## Which permissions are required? - **role-based grants** — A dedicated role holds USAGE on the warehouse and SELECT on the specific schemas required. Permissions are requested at the minimum scope the configured processes require. Unused scopes are not granted. ## Which processes use it? - Expense audit - Third-party due diligence - Data access review ## How do you revoke access? Access is revoked in Snowflake itself — by disabling the credential or removing the granted scopes — or in BRAIAN by disconnecting the integration. Processes already running stop at their next call to Snowflake and are held for review rather than completed with partial data; the interruption and the state of each process are recorded in the audit log. ## FAQ ### Does BRAIAN store data from Snowflake? BRAIAN reads what a process needs, when it needs it. Records retrieved from Snowflake are held only for the duration of the process and in the audit trail of the actions taken; Snowflake remains the system of record. ### What happens if the connection fails mid-process? The process stops at the failed step and is held for review. Nothing is written twice: completed writes stay recorded in the audit log and the remaining steps resume only once the connection is restored. ### Can permissions be scoped per agent? Yes. Scopes are defined per agent, not per system, so one agent can read while another cannot, on the same connection to Snowflake. --- # ServiceNow integration > BRAIAN connects to ServiceNow through Table API, OAuth. Agents can incident and request read, ticket creation and update and approval routing. Every action is scoped by the permissions granted to the integration and executed under a versioned policy. Each one is recorded in the audit log with the agent, timestamp and record touched. Source: https://aeterion.tech/en/integrations/servicenow Category: ITSM SecAgent and CcAgent read incidents and requests, create and update tickets, route approvals and look up configuration items. Writes follow the control regime configured for the process, so approvals can stay with a person. ## What can BRAIAN do? | Capability | Agent | Read or write | | --- | --- | --- | | Incident and request read | SecAgent | Read | | Ticket creation and update | CcAgent | Write | | Approval routing | SecAgent | Write | | CMDB lookup | SecAgent | Read | ## How does it connect? - **Connection method** — Table API, OAuth - **Credential** — A ServiceNow OAuth client bound to an integration user with a restricted role. Credentials are held in an encrypted secrets store. BRAIAN never stores end-user passwords. ## Which permissions are required? - **incident, sc_request, sysapproval_approver, cmdb_ci** — Table-level ACLs limited to the tables the configured processes read or write. Permissions are requested at the minimum scope the configured processes require. Unused scopes are not granted. ## Which processes use it? - Access certification - SLA - Users request level 1-2-3 ## How do you revoke access? Access is revoked in ServiceNow itself — by disabling the credential or removing the granted scopes — or in BRAIAN by disconnecting the integration. Processes already running stop at their next call to ServiceNow and are held for review rather than completed with partial data; the interruption and the state of each process are recorded in the audit log. ## FAQ ### Does BRAIAN store data from ServiceNow? BRAIAN reads what a process needs, when it needs it. Records retrieved from ServiceNow are held only for the duration of the process and in the audit trail of the actions taken; ServiceNow remains the system of record. ### What happens if the connection fails mid-process? The process stops at the failed step and is held for review. Nothing is written twice: completed writes stay recorded in the audit log and the remaining steps resume only once the connection is restored. ### Can permissions be scoped per agent? Yes. Scopes are defined per agent, not per system, so one agent can read while another cannot, on the same connection to ServiceNow. --- # Jira integration > BRAIAN connects to Jira through REST API v3, OAuth 2.0. Agents can issue read and creation, transition management and comment posting. Every action is scoped by the permissions granted to the integration and executed under a versioned policy. Each one is recorded in the audit log with the agent, timestamp and record touched. Source: https://aeterion.tech/en/integrations/jira Category: ITSM SecAgent reads and creates issues, moves them through the workflow transitions a project defines and posts comments that record what was done. Project access is granted per project, never across the whole site. ## What can BRAIAN do? | Capability | Agent | Read or write | | --- | --- | --- | | Issue read and creation | SecAgent | Read and write | | Transition management | SecAgent | Write | | Comment posting | SecAgent | Write | | Project lookup | SecAgent | Read | ## How does it connect? - **Connection method** — REST API v3, OAuth 2.0 - **Credential** — An Atlassian OAuth 2.0 app with a refresh token held in the secrets store. Credentials are held in an encrypted secrets store. BRAIAN never stores end-user passwords. ## Which permissions are required? - **read:jira-work / write:jira-work** — Read and write on issues in the projects explicitly enabled for the integration. Permissions are requested at the minimum scope the configured processes require. Unused scopes are not granted. ## Which processes use it? - Data access review - Access certification ## How do you revoke access? Access is revoked in Jira itself — by disabling the credential or removing the granted scopes — or in BRAIAN by disconnecting the integration. Processes already running stop at their next call to Jira and are held for review rather than completed with partial data; the interruption and the state of each process are recorded in the audit log. ## FAQ ### Does BRAIAN store data from Jira? BRAIAN reads what a process needs, when it needs it. Records retrieved from Jira are held only for the duration of the process and in the audit trail of the actions taken; Jira remains the system of record. ### What happens if the connection fails mid-process? The process stops at the failed step and is held for review. Nothing is written twice: completed writes stay recorded in the audit log and the remaining steps resume only once the connection is restored. ### Can permissions be scoped per agent? Yes. Scopes are defined per agent, not per system, so one agent can read while another cannot, on the same connection to Jira. --- # Microsoft SharePoint integration > BRAIAN connects to Microsoft SharePoint through Microsoft Graph API, application permissions with sites.selected scope. Agents can document retrieval, metadata read and library search. Every action is scoped by the permissions granted to the integration and executed under a versioned policy. Each one is recorded in the audit log with the agent, timestamp and record touched. Source: https://aeterion.tech/en/integrations/microsoft-sharepoint Category: Document Management LegalAgent, HRAgent and RiskAgent retrieve documents and their metadata from the specific sites a process covers. Access is granted with the sites.selected scope, so the integration never sees the whole tenant. ## What can BRAIAN do? | Capability | Agent | Read or write | | --- | --- | --- | | Document retrieval | LegalAgent | Read | | Metadata read | RiskAgent | Read | | Library search | HRAgent | Read | | Permission-aware access | All agents | Read | ## How does it connect? - **Connection method** — Microsoft Graph API, application permissions with sites.selected scope - **Credential** — An Entra ID application with a certificate credential, granted access to named sites only. Credentials are held in an encrypted secrets store. BRAIAN never stores end-user passwords. ## Which permissions are required? - **Sites.Selected** — Site-scoped, never tenant-wide: an administrator adds each site explicitly. - **Files.Read.All (within selected sites)** — Read access to the documents inside those sites, with their existing permissions honoured. Permissions are requested at the minimum scope the configured processes require. Unused scopes are not granted. ## Which processes use it? - Contract analysis - Clause extraction - Employee onboarding ## How do you revoke access? Access is revoked in Microsoft SharePoint itself — by disabling the credential or removing the granted scopes — or in BRAIAN by disconnecting the integration. Processes already running stop at their next call to Microsoft SharePoint and are held for review rather than completed with partial data; the interruption and the state of each process are recorded in the audit log. ## FAQ ### Does BRAIAN store data from Microsoft SharePoint? BRAIAN reads what a process needs, when it needs it. Records retrieved from Microsoft SharePoint are held only for the duration of the process and in the audit trail of the actions taken; Microsoft SharePoint remains the system of record. ### What happens if the connection fails mid-process? The process stops at the failed step and is held for review. Nothing is written twice: completed writes stay recorded in the audit log and the remaining steps resume only once the connection is restored. ### Can permissions be scoped per agent? Yes. Scopes are defined per agent, not per system, so one agent can read while another cannot, on the same connection to Microsoft SharePoint. --- # Google Drive integration > BRAIAN connects to Google Drive through Google Drive API, service account with domain-wide delegation scoped to specific folders. Agents can file retrieval, folder search and metadata read. Every action is scoped by the permissions granted to the integration and executed under a versioned policy. Each one is recorded in the audit log with the agent, timestamp and record touched. Source: https://aeterion.tech/en/integrations/google-drive Category: Document Management Agents retrieve files and read metadata from the folders a process is configured to cover. Delegation is scoped to those folders, so documents outside them remain out of reach. ## What can BRAIAN do? | Capability | Agent | Read or write | | --- | --- | --- | | File retrieval | LegalAgent | Read | | Folder search | HRAgent | Read | | Metadata read | LegalAgent | Read | ## How does it connect? - **Connection method** — Google Drive API, service account with domain-wide delegation scoped to specific folders - **Credential** — A Google service account key held in the secrets store, with delegation limited to named folders. Credentials are held in an encrypted secrets store. BRAIAN never stores end-user passwords. ## Which permissions are required? - **drive.readonly (delegated)** — Read-only access to the delegated folders; no write scope is requested. - **drive.metadata.readonly** — File names, owners and modification dates used to locate the right document. Permissions are requested at the minimum scope the configured processes require. Unused scopes are not granted. ## Which processes use it? - Contract analysis - Employee onboarding ## How do you revoke access? Access is revoked in Google Drive itself — by disabling the credential or removing the granted scopes — or in BRAIAN by disconnecting the integration. Processes already running stop at their next call to Google Drive and are held for review rather than completed with partial data; the interruption and the state of each process are recorded in the audit log. ## FAQ ### Does BRAIAN store data from Google Drive? BRAIAN reads what a process needs, when it needs it. Records retrieved from Google Drive are held only for the duration of the process and in the audit trail of the actions taken; Google Drive remains the system of record. ### What happens if the connection fails mid-process? The process stops at the failed step and is held for review. Nothing is written twice: completed writes stay recorded in the audit log and the remaining steps resume only once the connection is restored. ### Can permissions be scoped per agent? Yes. Scopes are defined per agent, not per system, so one agent can read while another cannot, on the same connection to Google Drive. --- # Microsoft Teams integration > BRAIAN connects to Microsoft Teams through Microsoft Graph API + bot registration. Agents can approval requests, escalation notifications and carol conversational access. Every action is scoped by the permissions granted to the integration and executed under a versioned policy. Each one is recorded in the audit log with the agent, timestamp and record touched. Source: https://aeterion.tech/en/integrations/microsoft-teams Category: Communication Approval requests and escalations reach the responsible person in Teams, and Carol can be queried directly in a chat. The conversation happens in Teams; the decision and its rationale are recorded in BRAIAN. ## What can BRAIAN do? | Capability | Agent | Read or write | | --- | --- | --- | | Approval requests | All agents | Write | | Escalation notifications | All agents | Write | | Carol conversational access | Carol | Read and write | ## How does it connect? - **Connection method** — Microsoft Graph API + bot registration - **Credential** — An Entra ID application registered as a bot, with a certificate credential in the secrets store. Credentials are held in an encrypted secrets store. BRAIAN never stores end-user passwords. ## Which permissions are required? - **ChannelMessage.Send / Chat.ReadWrite (bot)** — Sending approval and escalation messages in the channels and chats the bot is added to. - **User.Read.All** — Resolving the person responsible for an approval from the directory. Permissions are requested at the minimum scope the configured processes require. Unused scopes are not granted. ## Which processes use it? - Policy compliance - Access certification - Users request level 1-2-3 Escalations surface in Teams; the decision is logged in BRAIAN. ## How do you revoke access? Access is revoked in Microsoft Teams itself — by disabling the credential or removing the granted scopes — or in BRAIAN by disconnecting the integration. Processes already running stop at their next call to Microsoft Teams and are held for review rather than completed with partial data; the interruption and the state of each process are recorded in the audit log. ## FAQ ### Does BRAIAN store data from Microsoft Teams? BRAIAN reads what a process needs, when it needs it. Records retrieved from Microsoft Teams are held only for the duration of the process and in the audit trail of the actions taken; Microsoft Teams remains the system of record. ### What happens if the connection fails mid-process? The process stops at the failed step and is held for review. Nothing is written twice: completed writes stay recorded in the audit log and the remaining steps resume only once the connection is restored. ### Can permissions be scoped per agent? Yes. Scopes are defined per agent, not per system, so one agent can read while another cannot, on the same connection to Microsoft Teams. --- # Slack integration > BRAIAN connects to Slack through Slack app, bot token with scoped permissions. Agents can approval requests, escalation notifications and carol conversational access. Every action is scoped by the permissions granted to the integration and executed under a versioned policy. Each one is recorded in the audit log with the agent, timestamp and record touched. Source: https://aeterion.tech/en/integrations/slack Category: Communication A scoped Slack app posts approval requests and escalations in the channels a process uses, and gives Carol a conversational entry point. Only the channels the app is invited to are reachable. ## What can BRAIAN do? | Capability | Agent | Read or write | | --- | --- | --- | | Approval requests | All agents | Write | | Escalation notifications | All agents | Write | | Carol conversational access | Carol | Read and write | ## How does it connect? - **Connection method** — Slack app, bot token with scoped permissions - **Credential** — A Slack bot token issued to the workspace app and held in the secrets store. Credentials are held in an encrypted secrets store. BRAIAN never stores end-user passwords. ## Which permissions are required? - **chat:write** — Posting messages in the channels the app has been invited to. - **users:read** — Matching an approver to their Slack account. Permissions are requested at the minimum scope the configured processes require. Unused scopes are not granted. ## Which processes use it? - Policy compliance - SLA - Access certification ## How do you revoke access? Access is revoked in Slack itself — by disabling the credential or removing the granted scopes — or in BRAIAN by disconnecting the integration. Processes already running stop at their next call to Slack and are held for review rather than completed with partial data; the interruption and the state of each process are recorded in the audit log. ## FAQ ### Does BRAIAN store data from Slack? BRAIAN reads what a process needs, when it needs it. Records retrieved from Slack are held only for the duration of the process and in the audit trail of the actions taken; Slack remains the system of record. ### What happens if the connection fails mid-process? The process stops at the failed step and is held for review. Nothing is written twice: completed writes stay recorded in the audit log and the remaining steps resume only once the connection is restored. ### Can permissions be scoped per agent? Yes. Scopes are defined per agent, not per system, so one agent can read while another cannot, on the same connection to Slack. --- # Microsoft Entra ID integration > BRAIAN connects to Microsoft Entra ID through Microsoft Graph API, application permissions. Agents can user and group synchronisation, role mapping to agent permissions and single sign-on. Every action is scoped by the permissions granted to the integration and executed under a versioned policy. Each one is recorded in the audit log with the agent, timestamp and record touched. Source: https://aeterion.tech/en/integrations/microsoft-entra-id Category: Identity Users and groups are synchronised from Entra ID and mapped to agent permissions, so the directory stays the single place where access is decided. Single sign-on and access review data use the same connection. ## What can BRAIAN do? | Capability | Agent | Read or write | | --- | --- | --- | | User and group synchronisation | All agents | Read | | Role mapping to agent permissions | All agents | Read | | Single sign-on | Carol | Read | | Access review data | SecAgent | Read | ## How does it connect? - **Connection method** — Microsoft Graph API, application permissions - **Credential** — An Entra ID application with a certificate credential; no directory write permission is requested. Credentials are held in an encrypted secrets store. BRAIAN never stores end-user passwords. ## Which permissions are required? - **User.Read.All** — Reading user attributes needed to resolve identity and language. - **GroupMember.Read.All** — Group membership, which determines what each agent and each Carol instance may see. - **AccessReview.Read.All** — Existing access review results, read only, used in certification processes. Permissions are requested at the minimum scope the configured processes require. Unused scopes are not granted. ## Which processes use it? - Data access review - Access certification - Employee onboarding Entra ID group membership maps directly to what each agent — and each Carol instance — is allowed to see. ## How do you revoke access? Access is revoked in Microsoft Entra ID itself — by disabling the credential or removing the granted scopes — or in BRAIAN by disconnecting the integration. Processes already running stop at their next call to Microsoft Entra ID and are held for review rather than completed with partial data; the interruption and the state of each process are recorded in the audit log. ## FAQ ### Does BRAIAN store data from Microsoft Entra ID? BRAIAN reads what a process needs, when it needs it. Records retrieved from Microsoft Entra ID are held only for the duration of the process and in the audit trail of the actions taken; Microsoft Entra ID remains the system of record. ### What happens if the connection fails mid-process? The process stops at the failed step and is held for review. Nothing is written twice: completed writes stay recorded in the audit log and the remaining steps resume only once the connection is restored. ### Can permissions be scoped per agent? Yes. Scopes are defined per agent, not per system, so one agent can read while another cannot, on the same connection to Microsoft Entra ID. --- # Okta integration > BRAIAN connects to Okta through Okta API, API token. Agents can user and group sync, single sign-on and lifecycle events. Every action is scoped by the permissions granted to the integration and executed under a versioned policy. Each one is recorded in the audit log with the agent, timestamp and record touched. Source: https://aeterion.tech/en/integrations/okta Category: Identity Users and groups are synchronised from Okta, single sign-on is handled by Okta itself and lifecycle events — joiners, movers, leavers — update what agents and Carol may reach. ## What can BRAIAN do? | Capability | Agent | Read or write | | --- | --- | --- | | User and group sync | All agents | Read | | Single sign-on | Carol | Read | | Lifecycle events | SecAgent | Read | ## How does it connect? - **Connection method** — Okta API, API token - **Credential** — An Okta API token issued to a service account and held in the secrets store. Credentials are held in an encrypted secrets store. BRAIAN never stores end-user passwords. ## Which permissions are required? - **okta.users.read** — User attributes needed to resolve identity. - **okta.groups.read** — Group membership, mapped to agent permissions. Permissions are requested at the minimum scope the configured processes require. Unused scopes are not granted. ## Which processes use it? - Access certification - Data access review ## How do you revoke access? Access is revoked in Okta itself — by disabling the credential or removing the granted scopes — or in BRAIAN by disconnecting the integration. Processes already running stop at their next call to Okta and are held for review rather than completed with partial data; the interruption and the state of each process are recorded in the audit log. ## FAQ ### Does BRAIAN store data from Okta? BRAIAN reads what a process needs, when it needs it. Records retrieved from Okta are held only for the duration of the process and in the audit trail of the actions taken; Okta remains the system of record. ### What happens if the connection fails mid-process? The process stops at the failed step and is held for review. Nothing is written twice: completed writes stay recorded in the audit log and the remaining steps resume only once the connection is restored. ### Can permissions be scoped per agent? Yes. Scopes are defined per agent, not per system, so one agent can read while another cannot, on the same connection to Okta. --- # AI agents for Finance > BRAIAN runs Finance work as governed software. FinAgent is the specialised agent responsible for the domain: it executes invoice reconciliation and expense audit under a versioned policy, with a defined control regime for each process. Every decision is logged with timestamp, agent and policy applied, and every escalation reaches a named person. Source: https://aeterion.tech/en/solutions/finance Built on BRAIAN. FinAgent runs Finance processes inside the systems your teams already use, under a versioned policy. ## Which processes run, and under which control regime? Each Finance process is bound to one of two regimes. The regime is part of the policy, not an operating habit: it is enforced on every run. - **Invoice reconciliation** — Human-in-the-loop — the agent prepares the decision and a named person approves it before anything is written back to the source system. - **Expense audit** — Human-over-the-loop — the agent executes and writes back within its policy; a person reviews the audit log and is alerted whenever the policy escalates a case. ## FinAgent, the agent responsible for Finance FinAgent holds only the tools its processes require. Its permissions, approval thresholds, model restrictions and data residency come from the policy version attached to each run — not from the agent itself. - Scoped access to the Finance systems only, never across domains. - Approval thresholds and model restrictions applied at runtime, on every action. - Data residency in Switzerland and the EU. - Every decision written to the append-only audit log. ## One operating system, nine domains Finance runs on the same execution engine, the same policy layer and the same audit log as the other seven domains. Adding a domain does not add a platform. ## Which systems does FinAgent connect to? Each connection is scoped, authenticated and logged at the boundary. Open an integration to see its capabilities, read or write access and required permissions. ### SAP S/4HANA ERP — scoped connection, logged at the boundary. ### Microsoft Dynamics 365 ERP — scoped connection, logged at the boundary. ### Abacus ERP — scoped connection, logged at the boundary. ### Odoo ERP — scoped connection, logged at the boundary. ## See FinAgent run a real Finance process A pilot runs one process end to end, in your environment, with metrics from day one. --- # AI agents for Legal > BRAIAN runs Legal work as governed software. LegalAgent is the specialised agent responsible for the domain: it executes contract analysis and clause extraction under a versioned policy, with a defined control regime for each process. Every decision is logged with timestamp, agent and policy applied, and every escalation reaches a named person. Source: https://aeterion.tech/en/solutions/legal Built on BRAIAN. LegalAgent runs Legal processes inside the systems your teams already use, under a versioned policy. ## Which processes run, and under which control regime? Each Legal process is bound to one of two regimes. The regime is part of the policy, not an operating habit: it is enforced on every run. - **Contract analysis** — Human-in-the-loop — the agent prepares the decision and a named person approves it before anything is written back to the source system. - **Clause extraction** — Human-over-the-loop — the agent executes and writes back within its policy; a person reviews the audit log and is alerted whenever the policy escalates a case. ## LegalAgent, the agent responsible for Legal LegalAgent holds only the tools its processes require. Its permissions, approval thresholds, model restrictions and data residency come from the policy version attached to each run — not from the agent itself. - Scoped access to the Legal systems only, never across domains. - Approval thresholds and model restrictions applied at runtime, on every action. - Data residency in Switzerland and the EU. - Every decision written to the append-only audit log. ## One operating system, nine domains Legal runs on the same execution engine, the same policy layer and the same audit log as the other seven domains. Adding a domain does not add a platform. ## Which systems does LegalAgent connect to? Each connection is scoped, authenticated and logged at the boundary. Open an integration to see its capabilities, read or write access and required permissions. ### Salesforce CRM — scoped connection, logged at the boundary. ### Microsoft SharePoint Document Management — scoped connection, logged at the boundary. ### Google Drive Document Management — scoped connection, logged at the boundary. ## Related solution: procurement ### AI agents for procurement Procurement runs on its own dedicated agent, ProcurementAgent — supplier onboarding, due diligence, contract analysis and renewals. Same engine, same policy. ## See LegalAgent run a real Legal process A pilot runs one process end to end, in your environment, with metrics from day one. --- # AI agents for Risk > BRAIAN runs Risk work as governed software. RiskAgent is the specialised agent responsible for the domain: it executes third-party due diligence and supplier onboarding under a versioned policy, with a defined control regime for each process. Every decision is logged with timestamp, agent and policy applied, and every escalation reaches a named person. Source: https://aeterion.tech/en/solutions/risk Built on BRAIAN. RiskAgent runs Risk processes inside the systems your teams already use, under a versioned policy. ## Which processes run, and under which control regime? Each Risk process is bound to one of two regimes. The regime is part of the policy, not an operating habit: it is enforced on every run. - **Third-party due diligence** — Human-in-the-loop — the agent prepares the decision and a named person approves it before anything is written back to the source system. - **Supplier onboarding** — Human-in-the-loop — the agent prepares the decision and a named person approves it before anything is written back to the source system. ## RiskAgent, the agent responsible for Risk RiskAgent holds only the tools its processes require. Its permissions, approval thresholds, model restrictions and data residency come from the policy version attached to each run — not from the agent itself. - Scoped access to the Risk systems only, never across domains. - Approval thresholds and model restrictions applied at runtime, on every action. - Data residency in Switzerland and the EU. - Every decision written to the append-only audit log. ## One operating system, nine domains Risk runs on the same execution engine, the same policy layer and the same audit log as the other seven domains. Adding a domain does not add a platform. ## Which systems does RiskAgent connect to? Each connection is scoped, authenticated and logged at the boundary. Open an integration to see its capabilities, read or write access and required permissions. ### SAP S/4HANA ERP — scoped connection, logged at the boundary. ### Microsoft Dynamics 365 ERP — scoped connection, logged at the boundary. ### Odoo ERP — scoped connection, logged at the boundary. ### Microsoft SharePoint Document Management — scoped connection, logged at the boundary. ## Related solution: procurement ### AI agents for procurement Procurement runs on its own dedicated agent, ProcurementAgent — supplier onboarding, due diligence, contract analysis and renewals. Same engine, same policy. ## See RiskAgent run a real Risk process A pilot runs one process end to end, in your environment, with metrics from day one. --- # AI agents for HR > BRAIAN runs HR work as governed software. HRAgent is the specialised agent responsible for the domain: it executes employee onboarding and policy compliance under a versioned policy, with a defined control regime for each process. Every decision is logged with timestamp, agent and policy applied, and every escalation reaches a named person. Source: https://aeterion.tech/en/solutions/hr Built on BRAIAN. HRAgent runs HR processes inside the systems your teams already use, under a versioned policy. ## Which processes run, and under which control regime? Each HR process is bound to one of two regimes. The regime is part of the policy, not an operating habit: it is enforced on every run. - **Employee onboarding** — Human-over-the-loop — the agent executes and writes back within its policy; a person reviews the audit log and is alerted whenever the policy escalates a case. - **Policy compliance** — Human-in-the-loop — the agent prepares the decision and a named person approves it before anything is written back to the source system. ## HRAgent, the agent responsible for HR HRAgent holds only the tools its processes require. Its permissions, approval thresholds, model restrictions and data residency come from the policy version attached to each run — not from the agent itself. - Scoped access to the HR systems only, never across domains. - Approval thresholds and model restrictions applied at runtime, on every action. - Data residency in Switzerland and the EU. - Every decision written to the append-only audit log. ## One operating system, nine domains HR runs on the same execution engine, the same policy layer and the same audit log as the other seven domains. Adding a domain does not add a platform. ## Which systems does HRAgent connect to? Each connection is scoped, authenticated and logged at the boundary. Open an integration to see its capabilities, read or write access and required permissions. ### Abacus ERP — scoped connection, logged at the boundary. ### Microsoft SharePoint Document Management — scoped connection, logged at the boundary. ### Google Drive Document Management — scoped connection, logged at the boundary. ## See HRAgent run a real HR process A pilot runs one process end to end, in your environment, with metrics from day one. --- # AI agents for Sales > BRAIAN runs Sales work as governed software. SalesAgent is the specialised agent responsible for the domain: it executes offering and order confirmation and crm under a versioned policy, with a defined control regime for each process. Every decision is logged with timestamp, agent and policy applied, and every escalation reaches a named person. Source: https://aeterion.tech/en/solutions/sales Built on BRAIAN. SalesAgent runs Sales processes inside the systems your teams already use, under a versioned policy. ## Which processes run, and under which control regime? Each Sales process is bound to one of two regimes. The regime is part of the policy, not an operating habit: it is enforced on every run. - **Offering** — Human-over-the-loop — the agent executes and writes back within its policy; a person reviews the audit log and is alerted whenever the policy escalates a case. - **Order confirmation** — Human-in-the-loop — the agent prepares the decision and a named person approves it before anything is written back to the source system. - **CRM** — Human-over-the-loop — the agent executes and writes back within its policy; a person reviews the audit log and is alerted whenever the policy escalates a case. ## SalesAgent, the agent responsible for Sales SalesAgent holds only the tools its processes require. Its permissions, approval thresholds, model restrictions and data residency come from the policy version attached to each run — not from the agent itself. - Scoped access to the Sales systems only, never across domains. - Approval thresholds and model restrictions applied at runtime, on every action. - Data residency in Switzerland and the EU. - Every decision written to the append-only audit log. ## One operating system, nine domains Sales runs on the same execution engine, the same policy layer and the same audit log as the other seven domains. Adding a domain does not add a platform. ## Which systems does SalesAgent connect to? Each connection is scoped, authenticated and logged at the boundary. Open an integration to see its capabilities, read or write access and required permissions. ### Microsoft Dynamics 365 ERP — scoped connection, logged at the boundary. ### Salesforce CRM — scoped connection, logged at the boundary. ### HubSpot CRM — scoped connection, logged at the boundary. ## See SalesAgent run a real Sales process A pilot runs one process end to end, in your environment, with metrics from day one. --- # AI agents for Marketing > BRAIAN runs Marketing work as governed software. MaAgent is the specialised agent responsible for the domain: it executes inbound process and outbound process under a versioned policy, with a defined control regime for each process. Every decision is logged with timestamp, agent and policy applied, and every escalation reaches a named person. Source: https://aeterion.tech/en/solutions/marketing Built on BRAIAN. MaAgent runs Marketing processes inside the systems your teams already use, under a versioned policy. ## Which processes run, and under which control regime? Each Marketing process is bound to one of two regimes. The regime is part of the policy, not an operating habit: it is enforced on every run. - **Inbound process** — Human-over-the-loop — the agent executes and writes back within its policy; a person reviews the audit log and is alerted whenever the policy escalates a case. - **Outbound process** — Human-over-the-loop — the agent executes and writes back within its policy; a person reviews the audit log and is alerted whenever the policy escalates a case. ## MaAgent, the agent responsible for Marketing MaAgent holds only the tools its processes require. Its permissions, approval thresholds, model restrictions and data residency come from the policy version attached to each run — not from the agent itself. - Scoped access to the Marketing systems only, never across domains. - Approval thresholds and model restrictions applied at runtime, on every action. - Data residency in Switzerland and the EU. - Every decision written to the append-only audit log. ## One operating system, nine domains Marketing runs on the same execution engine, the same policy layer and the same audit log as the other seven domains. Adding a domain does not add a platform. ## Which systems does MaAgent connect to? Each connection is scoped, authenticated and logged at the boundary. Open an integration to see its capabilities, read or write access and required permissions. ### HubSpot CRM — scoped connection, logged at the boundary. ## See MaAgent run a real Marketing process A pilot runs one process end to end, in your environment, with metrics from day one. --- # AI agents for IT Operations > BRAIAN runs IT Operations work as governed software. SecAgent is the specialised agent responsible for the domain: it executes data access review and access certification under a versioned policy, with a defined control regime for each process. Every decision is logged with timestamp, agent and policy applied, and every escalation reaches a named person. Source: https://aeterion.tech/en/solutions/it-operations Built on BRAIAN. SecAgent runs IT Operations processes inside the systems your teams already use, under a versioned policy. ## Which processes run, and under which control regime? Each IT Operations process is bound to one of two regimes. The regime is part of the policy, not an operating habit: it is enforced on every run. - **Data access review** — Human-in-the-loop — the agent prepares the decision and a named person approves it before anything is written back to the source system. - **Access certification** — Human-in-the-loop — the agent prepares the decision and a named person approves it before anything is written back to the source system. ## SecAgent, the agent responsible for IT Operations SecAgent holds only the tools its processes require. Its permissions, approval thresholds, model restrictions and data residency come from the policy version attached to each run — not from the agent itself. - Scoped access to the IT Operations systems only, never across domains. - Approval thresholds and model restrictions applied at runtime, on every action. - Data residency in Switzerland and the EU. - Every decision written to the append-only audit log. ## One operating system, nine domains IT Operations runs on the same execution engine, the same policy layer and the same audit log as the other seven domains. Adding a domain does not add a platform. ## Which systems does SecAgent connect to? Each connection is scoped, authenticated and logged at the boundary. Open an integration to see its capabilities, read or write access and required permissions. ### ServiceNow ITSM — scoped connection, logged at the boundary. ### Jira ITSM — scoped connection, logged at the boundary. ## See SecAgent run a real IT Operations process A pilot runs one process end to end, in your environment, with metrics from day one. --- # AI agents for Customer Care > BRAIAN runs Customer Care work as governed software. CcAgent is the specialised agent responsible for the domain: it executes sla and user request level 1-2-3 under a versioned policy, with a defined control regime for each process. Every decision is logged with timestamp, agent and policy applied, and every escalation reaches a named person. Source: https://aeterion.tech/en/solutions/customer-care Built on BRAIAN. CcAgent runs Customer Care processes inside the systems your teams already use, under a versioned policy. ## Which processes run, and under which control regime? Each Customer Care process is bound to one of two regimes. The regime is part of the policy, not an operating habit: it is enforced on every run. - **SLA** — Human-over-the-loop — the agent executes and writes back within its policy; a person reviews the audit log and is alerted whenever the policy escalates a case. - **User request level 1-2-3** — Human-over-the-loop — the agent executes and writes back within its policy; a person reviews the audit log and is alerted whenever the policy escalates a case. ## CcAgent, the agent responsible for Customer Care CcAgent holds only the tools its processes require. Its permissions, approval thresholds, model restrictions and data residency come from the policy version attached to each run — not from the agent itself. - Scoped access to the Customer Care systems only, never across domains. - Approval thresholds and model restrictions applied at runtime, on every action. - Data residency in Switzerland and the EU. - Every decision written to the append-only audit log. ## One operating system, nine domains Customer Care runs on the same execution engine, the same policy layer and the same audit log as the other seven domains. Adding a domain does not add a platform. ## Which systems does CcAgent connect to? Each connection is scoped, authenticated and logged at the boundary. Open an integration to see its capabilities, read or write access and required permissions. ### ServiceNow ITSM — scoped connection, logged at the boundary. ## See CcAgent run a real Customer Care process A pilot runs one process end to end, in your environment, with metrics from day one. --- # AI agents for procurement > Procurement on BRAIAN runs on a dedicated agent. ProcurementAgent executes supplier onboarding, third-party due diligence and contract work under the same versioned policies as every domain agent. Every decision is logged with timestamp, agent and policy applied, and every escalation reaches a named person. Source: https://aeterion.tech/en/solutions/procurement Built on BRAIAN. Procurement is a cross-domain solution with a dedicated agent: ProcurementAgent, running under the same versioned policies as every domain agent. ## Processes, agent and control regime Each procurement process is executed by ProcurementAgent. The control regime is part of the policy, not an operating habit: it is enforced on every run. - **Supplier onboarding** — Agent: ProcurementAgent · Human-over-the-loop — the agent collects and verifies supplier data and writes back within its policy; a person reviews the audit log. - **Third-party due diligence** — Agent: ProcurementAgent · Human-in-the-loop — the agent prepares the assessment and a named person approves it before anything is recorded. - **Contract analysis** — Agent: ProcurementAgent · Human-in-the-loop — the agent extracts clauses, obligations and deviations; a named person approves the review. - **Vendor contract renewal** — Agent: ProcurementAgent · Human-over-the-loop — the agent executes the renewal within its policy and thresholds; a person reviews the audit log. ## One engine, one audit log, one policy model Procurement processes run on BRAIAN's dedicated ProcurementAgent. One engine, one audit log, one policy model. ## Where does procurement meet the domains? ### Risk — RiskAgent Supplier onboarding and third-party due diligence are also risk-domain processes. ### Legal — LegalAgent Contract analysis and vendor contract renewal are also legal-domain processes. ## See ProcurementAgent run a procurement process end to end A pilot runs one process end to end, in your environment, with metrics from day one. --- # Security of the BRAIAN platform > BRAIAN applies enterprise security controls to AI execution. Access is granted per role and per connector, never globally. Credentials live in the control plane and are never exposed to prompts. Data is encrypted in transit and at rest, environments are isolated, and every agent action is recorded with the policy version that authorised it. Source: https://aeterion.tech/en/security Least privilege by default, encrypted data paths, isolated environments and a complete record of who did what, on which system. ## Platform controls - Single sign-on through your identity provider, with role-based access and enforced multi-factor authentication. - Least-privilege connector permissions, scoped per process and per environment. - Secrets stored encrypted in the control plane, rotated without touching process definitions. - Encryption in transit (TLS 1.3) and at rest (AES-256). - Separate development, staging and production environments with separate credentials. - Append-only audit log of configuration changes, approvals and agent actions. ## AI-specific risks we control - **Prompt injection** — Untrusted content is isolated from instruction context, and tool access is authorised by policy rather than by model output. - **Data leakage** — Redaction rules run before any request leaves the environment, and model routing can be restricted by jurisdiction. - **Over-permissioned agents** — An agent inherits only the permissions of the step it runs, for the duration of that step. - **Silent drift** — Model, prompt and policy versions are pinned and recorded, so behaviour change is attributable. ## Operating practice - Change management: configuration and releases pass a review and are reversible. - Vulnerability management with dependency scanning and a defined patch window. - Backups with tested restore procedures, and a documented business continuity plan. - Independent penetration testing, with findings tracked to closure. - Incident response with defined notification paths for customers. ## FAQ ### Where is the platform hosted? In Switzerland or the European Union, or inside your own cloud tenancy. Hosting location is chosen at contract time and does not change silently. ### Do you train models on our data? No. Your data is not used to train models. Model providers are called under contractual terms that exclude training on submitted content. ### Can we run a security review before signing? Yes. We support security questionnaires, architecture reviews and, where required, a customer-run penetration test on a dedicated environment. ## Send us your security review We answer questionnaires and walk your security team through the architecture and controls. --- # Compliance for AI that actually runs processes > BRAIAN produces the evidence European supervision expects. Each process carries a risk classification, named human oversight, a data-protection basis and a versioned record of every decision. Documentation required by the EU AI Act, the General Data Protection Regulation (GDPR) and the Swiss Federal Act on Data Protection (nLPD) comes from the runtime. Not from manual work before an audit. Source: https://aeterion.tech/en/compliance Swiss and European rules do not ask whether AI is clever. They ask who is accountable, what was decided, and whether you can prove it. ## Frameworks we map to - **EU AI Act** — Risk classification per process, documented human oversight, technical documentation, logging and post-market monitoring produced by the runtime. - **GDPR** — Lawful basis recorded per process, data minimisation through redaction, retention policy, records of processing and data-subject request support. - **Swiss FADP (nLPD)** — Swiss data residency, processing records and controller/processor responsibilities reflected in platform configuration. - **ISO/IEC 42001 and 27001** — The platform is built around these control sets; certification of the ÆTERION management system is in progress and the status is published on the trust page. ## How do compliance and security fit together? Compliance states which obligations the runtime evidence maps to. Security states the controls that make that evidence trustworthy. ### Security controls Least privilege, encryption, isolated environments, prompt-injection controls and the append-only audit log behind every record on this page. ### Trust center Certification status, sub-processors and service commitments, published and kept current. ## What does the runtime produce? - A register of AI use cases with owner, purpose, risk class and status. - Evidence per run: inputs, decision, model version, policy version, approver. - Human oversight records: who reviewed, what they changed, why. - Incident and deviation records with resolution and follow-up. - Exportable documentation packs for internal audit and supervisors. ## Responsibilities ÆTERION provides the platform, its controls and its documentation. Your organisation remains responsible for the purpose of each process, for the lawful basis of the data it uses and for the decisions it takes. The platform makes that responsibility exercisable instead of theoretical. ## Carol and employee data _Last updated: 20 September 2026_ Carol's personalisation involves employees' personal data. Under the GDPR and the Swiss FADP, that processing requires its own lawful basis — separate from the basis of the underlying business process — and employees have the right to be informed: which data is used, for what purpose, for how long and who to contact. The controller for that processing is your organisation; the platform records the basis and supports the information and access duties. ### What employee data does Carol personalise on? Carol personalises on work context, not on the person. Specifically: the employee's role and team, the permissions granted to them, the systems they are authorised to access, the processes they are involved in, and their interaction history within Carol. Carol does not process performance evaluations, HR records, private communications, or behavioural indicators. It does not build a behavioural profile of the employee, and it does not infer traits, productivity or engagement. Personalisation is bounded by the same permission model that governs every other part of BRAIAN: Carol cannot surface information the employee is not authorised to see. ### Are voice recordings retained? For how long and where are they processed? Voice input is transcribed to text in real time and the audio is discarded immediately after transcription. Audio recordings are not stored. Transcripts are retained for 30 days and are then deleted. Retention is configurable per deployment and can be set to zero. All processing — transcription and inference — takes place within Switzerland or the EU. Voice data is not transmitted outside the configured region and is not used to train any model, ours or a third party's. ### Can a manager access a team member's Carol conversations? No. Carol conversations are visible only to the employee who had them. Managers, administrators and ÆTERION personnel have no access to conversation content. What is recorded in the audit log is the action, not the conversation: if a conversation results in a business process being started, the audit log shows that the process was initiated, by whom and under which policy — not what was said. Access to conversation content is possible only through a documented exceptional-access procedure, which requires written authorisation from the organisation's data controller and is itself logged. This is a design constraint, not a configuration option. Swiss labour law prohibits systems designed to monitor employee behaviour, and Carol is built to that constraint. ### What happens to the personalised instance when an employee leaves the company? The personalised instance is deactivated when the employee's account is deactivated. Carol stops operating immediately. Personalisation data and conversation history are deleted within 30 days of deactivation. Audit records of business actions remain. If Carol was used to start a supplier onboarding or approve an expense, that action stays in the audit log under the organisation's business record retention policy — it is a record of a business decision, held on a separate legal basis from personalisation data. The two are deliberately separate: personal data is deleted, business records are preserved. ### Can Carol be used to evaluate employee performance? No. Carol produces no metrics on individual employees: not usage frequency, not question volume, not response quality, not any derived indicator. Carol is not an evaluation system and is not designed to become one. No report, export or API exposes per-employee activity data. Process metrics in BRAIAN measure processes, not the people who run them. ## FAQ ### Is the platform certified? ÆTERION operates to ISO/IEC 27001 and 42001 control sets; formal certification is in progress. We publish the current status rather than implying a certificate we do not yet hold. ### Does BRAIAN classify our processes automatically? It guides the classification and records it, including the reasoning. The decision stays with your compliance owner. ### Can auditors read the evidence directly? Yes. Read-only auditor access can be granted to the register and to traces, scoped by the control plane. ## Prepare your AI documentation once We review one process with your compliance team and show the evidence the platform produces. --- # Trust center > This page states where ÆTERION stands today: which security controls are in operation, which certifications are in progress, which sub-processors handle data, and what our service commitments are. When a status changes, this page changes with it, and the change is dated. Source: https://aeterion.tech/en/trust The current state of our controls, certifications, sub-processors and service commitments — published, not promised on request. ## Certification status - **ISO/IEC 27001** — Control set implemented; certification audit in preparation. Status updated as the audit progresses. - **ISO/IEC 42001** — AI management system implemented following the standard; certification in preparation. - **SOC 2 Type II** — Planned once the ISO programme completes. No report is available today. - **EU AI Act readiness** — Platform features for classification, oversight, logging and documentation are in production use. ## Data and sub-processors - Hosting: Swiss or EU regions, chosen per customer environment. - Model providers: called through the gateway under terms that exclude training on customer content. - A current sub-processor list is provided with the contract and updated with notice before any change. - Customer data is deleted on termination according to the retention terms agreed in the contract. ## Service commitments - **Availability** — Service levels are defined per plan and stated in the contract, with measured uptime reported to customers. - **Support** — Named support contacts with response times by severity. - **Incident notification** — Security incidents affecting customer data are notified without undue delay, with a written follow-up report. - **Exit** — Process definitions, policies and traces are exportable in open formats at any time. ## FAQ ### Can we receive your documentation under NDA? Yes. Security architecture documents, penetration-test summaries and policy documents are shared under a mutual NDA. ### How do we report a vulnerability? Write to hallo@aeterion.tech with the details. We acknowledge receipt and keep the reporter informed until the issue is closed. ## Ask for the full documentation pack Security architecture, sub-processor list and policy documents, shared under NDA. --- # Pricing built around processes, not seats > BRAIAN is licensed per environment and per governed process, with usage covering agent runs. A pilot starts with one production environment and a small number of processes; enterprise agreements add environments, data-residency options, dedicated support and contractual service levels. Every plan includes the control plane, orchestration, evaluation and observability — governance is not an upsell. Source: https://aeterion.tech/en/pricing You pay for the processes BRAIAN runs and the environments you operate, not for how many people open a dashboard. ## Plans ### Pilot One production environment, up to three governed processes, standard connectors, Swiss or EU hosting, business-hours support. Designed to put a first process live in weeks. ### Scale Multiple environments and process portfolios, custom connectors, SSO and role mapping, evaluation suites per process, priority support with defined response times. ### Enterprise Deployment in your own cloud, dedicated data residency, contractual service levels, security reviews, audit support and a named technical account contact. ## What determines the price? - **Environments** — Production, plus any staging or regional environments you operate separately. - **Governed processes** — The number of distinct business processes under BRAIAN's control plane. - **Run volume** — Agent runs per month, banded rather than metered per call, so bills stay predictable. - **Deployment** — Managed hosting or deployment into your own tenancy, which changes operating responsibilities. ## Compare the capabilities ### Platform features The full capability inventory, marked available or in development, for your shortlist checklist. ## What is always included? - Control plane with versioned policies and audit log. - Orchestration runtime with human approval steps. - Evaluation suites and release gates. - Traces, cost attribution and export. - Compliance documentation generated from the runtime. ## FAQ ### Why is there no price list? Because the variables are environments, processes and volume, not users. We give a fixed written quote after a short scoping conversation, and the quote holds for the contract term. ### Is there a minimum term? A pilot runs for a defined period with a fixed fee. Longer agreements are annual, with the option to add processes during the term. ### Are model costs included? Model usage is billed at cost through the gateway, or you bring your own provider contract. Either way, cost per process is visible in the platform. ## Get a written quote Tell us the processes you want to govern and the environments you run; we return a fixed quote. --- # Talk to the people who build the platform > Write to hallo@aeterion.tech or use the form on this site. We reply within one business day. A first session takes about forty-five minutes: you describe a process, we model it in BRAIAN and show the policies, the execution and the audit trail it produces. ÆTERION is based in Lugano, Switzerland, and works in English, Italian and German. Source: https://aeterion.tech/en/contact A demo with ÆTERION is a working session on one of your processes, not a slide deck. Bring the process; we bring the runtime. ## What should you expect? - **First session** — Forty-five minutes on one real process: current steps, decisions, systems and approvals. - **Second session** — That process modelled in BRAIAN, with policies and traces shown against your own example. - **Pilot** — A defined pilot scope with a fixed fee, a named owner on both sides and a date for going live. ## Reach us - Email: hallo@aeterion.tech - ÆTERION Ltd, Viale Stefano Franscini 16, 6900 Lugano, Switzerland - Languages: English, Italian, German - Security and vulnerability reports: hallo@aeterion.tech ## FAQ ### Do you work with small and mid-sized companies? Yes. The pilot plan exists for exactly that: one process, a fixed scope and a fixed fee. ### Do we need an AI team to start? No. You need a process owner who knows the steps and the decisions. The platform supplies the rest. ## Talk to us One process, forty-five minutes, the platform running against your own example. --- # What changed in BRAIAN > This page records platform releases. Each entry states what changed, why it changed and whether existing processes need action. Behaviour-changing releases are announced before they reach production environments, and every change is reflected in the documentation on the same day. Source: https://aeterion.tech/en/changelog Platform releases, with the change, the reason and what it means for processes already running. ## 2026 - **Q3 — Evaluation gates** — Release gates can now block a promotion when a suite regresses beyond a set threshold. Existing processes keep their previous behaviour until a threshold is configured. - **Q3 — Cost attribution** — Run cost is attributed per process and per team and exportable alongside traces. - **Q2 — Policy versioning** — Policies gained explicit versions with diff and rollback. No action required for running processes. - **Q2 — EU region** — Managed hosting became available in the European Union in addition to Switzerland. ## How do releases reach you? - Security fixes are applied to managed environments as soon as they are validated. - Feature releases reach staging first, then production on a schedule you can see. - Behaviour-changing releases are announced in advance with a migration note. - Self-hosted deployments receive versioned releases with upgrade instructions. ## Questions about a release? We explain what a change means for your processes before it reaches production. --- # Introduction > BRAIAN is an AI operating system: a software product that runs finance, legal, sales, marketing, procurement, risk and HR processes as governed automation. Agents execute the work, policies constrain what they may do, and every decision is logged, versioned and auditable across the systems a company already operates. Source: https://aeterion.tech/en/docs Last updated: 2026-09-20 ## What does this documentation cover? These pages describe how BRAIAN is modelled, deployed and operated. They are written for the people who run the platform: process owners, platform engineers, risk and compliance teams. - Core concepts: the six objects every BRAIAN deployment is built from. - Quickstart: from an empty workspace to a governed process running in a sandbox environment. - Guides: task-oriented walkthroughs for recurring operational work. - Integrations: how BRAIAN connects to SAP, Microsoft 365, Salesforce, ServiceNow and databases. - Governance and compliance: how runtime evidence maps to the EU AI Act, the General Data Protection Regulation (GDPR) and the Swiss Federal Act on Data Protection (nFADP). ## How is BRAIAN structured? A deployment has four layers. The control plane holds policies, credentials and environments. Orchestration turns a process definition into running work. Evaluation scores every run against expected outcomes. Observability records what happened, in an append-only audit log. - **Control plane** — Where policies, secrets, roles and environments are defined and versioned. - **Orchestration** — Executes process definitions: steps, agents, tool calls, retries and escalations. - **Evaluation** — Compares each run against expected outcomes and flags regressions before they reach production. - **Observability** — Append-only records of inputs, decisions, approvals and system calls for every run. ## Conventions used in these pages Definitions in YAML describe objects stored in the control plane. Command examples use the BRAIAN command line, which authenticates against the environment selected in your workspace. ```bash braian env use sandbox braian process list ``` > **Every page is available as markdown** — Append .md to any documentation URL to retrieve the same page as raw markdown, without navigation or styling. --- # Core concepts > BRAIAN models automated work with six objects. Processes define what runs, agents perform the steps, and policies constrain the agents. Escalations hand control back to a person, the audit log records every decision, and environments separate sandbox work from production. Everything else in the platform is built from these six. Source: https://aeterion.tech/en/docs/core-concepts Last updated: 2026-09-20 ## The six objects - **Process** — A versioned definition of a business procedure: its trigger, steps, inputs and expected outcome. - **Agent** — A configured worker that performs steps using a model, a set of tools and a scoped identity. - **Policy** — A rule enforced at runtime by the control plane, not a guideline written into a prompt. - **Escalation** — A structured handover to a named human role when a policy, a threshold or a confidence check requires it. - **Audit log** — The append-only record of inputs, model decisions, tool calls, approvals and outputs. - **Environment** — An isolated workspace — sandbox, staging or production — with its own credentials and data. ## How do they fit together? A trigger starts a process run in one environment. Orchestration assigns each step to an agent. Before any tool call, the control plane evaluates the policies that apply to that agent, that environment and that data. A denied call becomes an escalation. Every outcome is written to the audit log. > **Policies are not prompts** — Prompt instructions are advisory and can be overridden by the model. Policies are evaluated outside the model and cannot be argued with. ## Where should you go next? - Read Processes to learn how work is defined and versioned. - Read Policies before granting any agent write access to a connected system. - Read Environments before your first production run. --- # Processes > A process in BRAIAN is a versioned definition of a business procedure. It declares a trigger, an ordered set of steps, the agents responsible for those steps, the systems it may touch, and the outcome that counts as success. Every execution of a definition is called a run. Source: https://aeterion.tech/en/docs/core-concepts/processes Last updated: 2026-09-20 ## Anatomy of a process definition Definitions are declarative. They describe the work and its constraints; orchestration decides how to execute it, when to retry and when to stop. `invoice-approval.yaml` ```yaml name: invoice-approval owner: finance-operations trigger: type: event source: sap.invoice.received steps: - id: extract agent: document-agent output: invoice_fields - id: match agent: finance-agent tools: [sap.purchase_orders.read] - id: approve agent: finance-agent policy: finance.payment-threshold outcome: success: invoice_posted sla_minutes: 30 ``` ## Versions and runs Publishing a definition creates an immutable version. Runs are bound to the version that was active when they started, so a change to the definition never rewrites the history of work already completed. - Every run stores its definition version, environment and trigger payload. - Retries reuse the same version; they do not pick up an edit made mid-run. - Rolling back means activating an earlier version, which is itself an audited change. ## Outcomes and service levels A process declares what success means. Evaluation uses that declaration to score runs, and observability uses the service level to flag runs that are late, stalled or repeatedly escalated. > **A process without a declared outcome cannot be evaluated** — Definitions without an outcome block run, but they are excluded from evaluation scoring and from regression checks between versions. --- # Agents > An agent in BRAIAN is a configured worker that performs process steps. It combines a model, a defined set of tools, a scoped machine identity and the policies attached to it. Agents hold no standing credentials of their own: access is issued per run and expires with the run. Source: https://aeterion.tech/en/docs/core-concepts/agents Last updated: 2026-09-20 ## Agent configuration An agent declares what it can use, not what it should try. Anything outside the declared tool list is unreachable, regardless of what the model generates. `finance-agent.yaml` ```yaml name: finance-agent model: braian-reason-1 identity: svc-finance-agent tools: - sap.purchase_orders.read - sap.invoices.post - erp.vendor_master.read policies: - finance.payment-threshold - data.residency-ch-eu max_steps: 24 ``` ## Identity and credentials - Each agent maps to one machine identity in the control plane, never to a human account. - Credentials are minted per run, scoped to the declared tools, and revoked when the run ends. - Secrets are stored encrypted and are never returned to the model context. ## Limits on autonomy Agents are bounded by a step budget, a tool scope and the policies attached to them. When a bound is reached the run does not fail silently: it escalates with the full context of what was attempted. > **Avoid over-permissioned agents** — Grant one agent the tools for one job. A single agent holding read and write access across finance, HR and procurement removes the separation that makes the audit log meaningful. --- # Policies > A policy in BRAIAN is a rule the control plane enforces at runtime, before a tool call executes. Policies cover approval thresholds, data residency, model restrictions, field-level access and time windows. They are versioned, testable and independent of prompts, so no model output can relax them. Source: https://aeterion.tech/en/docs/core-concepts/policies Last updated: 2026-09-20 ## How does enforcement work? Every tool call passes through the control plane. The plane resolves the policies that apply to the agent, the environment and the data classification of the payload, then allows, denies or escalates the call. The decision and its reason are written to the audit log. `finance.payment-threshold.yaml` ```yaml name: finance.payment-threshold applies_to: tools: [sap.invoices.post] rules: - when: amount <= 10000 then: allow - when: amount <= 100000 then: escalate to: role:finance-controller - default: deny ``` ## Policy categories - **Approval** — Amount, risk or counterparty thresholds that require a named human role. - **Data residency** — Restricts processing and storage to declared regions, for example CH and EU only. - **Model restriction** — Limits which models may see which data classifications. - **Field access** — Masks or blocks specific fields, such as salary or identification numbers. - **Time window** — Allows execution only during defined operational hours. ## Testing before activation Policies are evaluated against recorded runs before they are activated, so their effect is known in advance. ```bash braian policy test finance.payment-threshold --against last-30d braian policy activate finance.payment-threshold --env production ``` --- # Escalations > An escalation in BRAIAN is a structured handover from an agent to a named human role. It carries the process run, the step, the blocked action, the policy or threshold that triggered it, and the evidence gathered so far. The run pauses until the role approves, rejects or amends the action. Source: https://aeterion.tech/en/docs/core-concepts/escalations Last updated: 2026-09-20 ## What triggers an escalation? - A policy returns escalate instead of allow or deny. - An agent reaches its step budget or exhausts its retries. - Evaluation scores the step below the confidence threshold declared for the process. - A connected system returns an inconsistency the process is not allowed to resolve alone. ## Routing and decisions Escalations are routed to roles, not to individuals, so operations continue when a person is unavailable. The decision is recorded with the identity of the approver, the timestamp and any amendment made to the proposed action. ```yaml escalation: route_to: role:finance-controller channels: [braian-console, email, slack] timeout_minutes: 240 on_timeout: reject ``` ## Escalations as a signal A rising escalation rate on one step usually means a definition is wrong, a policy is too narrow or an upstream system changed. Treat the rate as an operational metric, not as noise. > **Timeouts are decisions too** — An escalation that expires records an explicit outcome. It never resolves itself by allowing the blocked action. --- # Audit log > The BRAIAN audit log is the append-only record of everything a run did: trigger payload, definition version, model decisions, tool calls, policy evaluations, escalations, human approvals and final outputs. Entries cannot be edited or deleted, and each one is linked to the run and version that produced it. Source: https://aeterion.tech/en/docs/core-concepts/audit-log Last updated: 2026-09-20 ## What is captured? - The trigger, its source system and the definition version that handled it. - Each model decision with the inputs it was given, excluding secrets. - Every tool call, its parameters, its result status and its latency. - Every policy evaluation with the rule that matched and the decision it returned. - Every escalation, approver identity, decision and amendment. ## How long is data retained, and how do you export it? Retention is configured per environment and per data classification. Logs can be streamed to an external system so evidence lives where the compliance function already works. ```bash braian audit export --run 01JR4K7Q --format json braian audit stream --env production --sink siem ``` ## Using the log as evidence Because entries are produced by the runtime rather than assembled afterwards, they can be used directly in internal audits and regulatory reviews. See Governance and compliance for the mapping to specific obligations. > **Personal data in logs** — Field-level policies decide what is recorded. Configure masking before running a process on personal data, because entries cannot be edited afterwards. --- # Environments > An environment in BRAIAN is an isolated workspace with its own credentials, connected systems, policies and audit history. Deployments normally use three: sandbox for development, staging for evaluation against realistic data, and production for governed live work. Definitions are promoted between environments; data is never promoted with them. Source: https://aeterion.tech/en/docs/core-concepts/environments Last updated: 2026-09-20 ## The three environments - **Sandbox** — Development workspace with synthetic data and no write access to production systems. - **Staging** — Mirrors production integrations against a controlled dataset; used for evaluation runs before promotion. - **Production** — Live work under active policies, with full audit retention and escalation routing to real roles. ## Promotion Promotion moves a definition version, not its data or credentials. Each environment binds its own connection settings, so the same version behaves consistently while talking to the right systems. ```bash braian process promote invoice-approval --from staging --to production --version 7 ``` ## Hosting and residency Environments run either in the ÆTERION managed deployment in Switzerland or the EU, or inside the customer's own cloud account. The product is identical in both; only the operating boundary changes. > **Residency is enforced, not declared** — The data residency policy blocks processing outside the configured regions, including model calls, rather than relying on configuration alone. --- # Quickstart > This quickstart takes an empty BRAIAN workspace to a governed process running in the sandbox environment. You will authenticate, connect one system, define a process and an agent, attach an approval policy, run the process and read the resulting audit entries. It takes roughly thirty minutes. Source: https://aeterion.tech/en/docs/quickstart Last updated: 2026-09-20 ## 1. Authenticate and select an environment The command line authenticates through your organisation's identity provider and stores a short-lived session bound to one environment. ```bash braian login --org acme braian env use sandbox ``` ## 2. Connect a system Connections are created in the control plane and are scoped per environment. In sandbox, connect a read-only account so a mistake cannot reach live records. ```bash braian connection create sap \ --scopes purchase_orders.read,invoices.read \ --env sandbox ``` ## 3. Define an agent and a process Save the two definitions as files and apply them. Applying validates the tool scopes against the connection you created. ```bash braian apply -f finance-agent.yaml braian apply -f invoice-approval.yaml ``` ## 4. Attach a policy and run Attach an approval threshold before the first run, then trigger the process with a sample payload. ```bash braian apply -f finance.payment-threshold.yaml braian process run invoice-approval --input ./sample-invoice.json ``` ## 5. Read what happened Open the run in the console or inspect it from the command line. Every step shows the agent, the policy decision and the elapsed time. ```bash braian run show --last braian audit export --run last --format json ``` > **Next step** — Before promoting anything to production, read Environments and Policies. Production runs require an activated policy set and a routed escalation role. --- # Guides > Guides are task-oriented walkthroughs for operating BRAIAN after the quickstart. Each guide solves one recurring job end to end: running a first real process, writing a policy. It states its prerequisites, the commands involved and the way to verify the result before moving work to production. Source: https://aeterion.tech/en/docs/guides Last updated: 2026-09-20 ## Available guides - **Run your first process** — Take one real, low-risk procedure from definition to a monitored sandbox run with a declared outcome. - **Write a policy** — Express an approval threshold as an enforced rule, test it against recorded runs and activate it safely. ## How do you use them? Guides assume a working sandbox environment and at least one connection, as produced by the quickstart. They are written to be followed in order within a single session, and each one ends with a verification step. --- # Run your first process > This guide takes one real business procedure from a written description to a monitored run in sandbox. You will choose a low-risk process, describe its steps and outcome, and assign an agent with a narrow tool scope. You then run it against recorded inputs and compare the result with the outcome you declared. Source: https://aeterion.tech/en/docs/guides/run-your-first-process Last updated: 2026-09-20 ## Choose the right process The first process should be frequent enough to produce signal within days and contained enough that an error is recoverable. - Runs at least fifty times a month. - Has a written outcome someone can verify in under a minute. - Touches two systems at most. - Has an owner who can approve escalations during working hours. ## Describe it as a definition Write the steps as they happen today, including the checks a person performs. Those checks become policies later; do not drop them at this stage. `vendor-onboarding.yaml` ```yaml name: vendor-onboarding owner: procurement trigger: type: form source: procurement.vendor_request steps: - id: verify-registry agent: research-agent tools: [registry.company_lookup] - id: check-sanctions agent: risk-agent tools: [compliance.sanctions_screen] - id: create-record agent: procurement-agent tools: [erp.vendor_master.write] outcome: success: vendor_record_created sla_minutes: 120 ``` ## Run against recorded inputs Replay real requests from the past weeks instead of inventing test cases. Recorded inputs expose the exceptions that written procedures rarely mention. ```bash braian process run vendor-onboarding --replay ./requests-august.jsonl ``` ## Verify before you promote - Every completed run reaches the declared outcome, or escalates with a reason you accept. - No step calls a tool outside the agent's declared scope. - The audit entries contain enough context for the process owner to reconstruct a decision. > **Do not promote on volume alone** — A high completion rate in sandbox with synthetic data says little. Promote only after a replay of real inputs reaches the declared outcome. --- # Write a policy > This guide turns an existing control — an approval threshold, a residency requirement, a field restriction — into a BRAIAN policy enforced at runtime. You will express the rule, scope it to the tools it protects, test it against recorded runs, review its predicted effect and activate it in one environment at a time. Source: https://aeterion.tech/en/docs/guides/write-a-policy Last updated: 2026-09-20 ## Start from a control that already exists Most organisations already have the rule written somewhere: a signature matrix, a data protection register, an internal control framework. Translate that rule rather than inventing a new one, so the enforced behaviour matches the approved behaviour. ## Express and scope the rule A policy names the tools it protects. Anything outside that scope is unaffected, which keeps policies small and reviewable. `hr.field-access.yaml` ```yaml name: hr.field-access applies_to: tools: [hris.employee.read] rules: - mask_fields: [salary, iban, national_id] when: agent != hr-payroll-agent - default: allow ``` ## Test against recorded runs Testing replays the policy over historical runs and reports which calls would have been allowed, escalated or denied. Review the denials before activation: a policy that blocks routine work will be bypassed by people rather than followed. ```bash braian policy test hr.field-access --against last-90d --report ./policy-impact.json ``` ## Activate one environment at a time ```bash braian policy activate hr.field-access --env staging braian policy activate hr.field-access --env production ``` > **Activation is audited** — Each activation records who activated the policy, in which environment and with which version, so control changes are traceable alongside process runs. --- # Integrations > An integration in BRAIAN is a scoped connection to a system a company already runs — SAP, Microsoft 365, Salesforce, ServiceNow, Slack, PostgreSQL, Snowflake, Jira. Connections are created per environment, expose named tools instead of raw credentials, and every call through them is recorded in the audit log. Source: https://aeterion.tech/en/docs/integrations Last updated: 2026-09-20 ## How do connections work? A connection holds the credentials and the scope. It publishes named tools, such as sap.invoices.post, which agents may declare. An agent never receives the credential itself, only permission to call a tool. ```bash braian connection create salesforce \ --scopes opportunities.read,accounts.read \ --env staging braian connection tools salesforce ``` ## Supported systems - **SAP** — Purchase orders, invoices, vendor master records, posting with approval policies. - **Microsoft 365** — Mail, calendar, SharePoint and Teams content within delegated scopes. - **Salesforce** — Accounts, opportunities, cases and activity history. - **ServiceNow** — Incidents, requests and change records. - **Slack** — Escalation delivery and structured approvals in channel. - **PostgreSQL and Snowflake** — Read access to operational and analytical data under field-level policies. - **Jira** — Issues, transitions and comments for engineering and operations processes. ## Custom systems Systems without a packaged connector are integrated through an HTTP connection that declares its own tools, authentication and rate limits. Custom tools behave like packaged ones: policy-checked, scoped per environment and audited. > **Write scopes need a policy** — A connection with write scopes cannot be attached to an agent in production until at least one policy governs the writing tools. --- # Governance and compliance > Governance in BRAIAN means controls enforced by the runtime and evidence produced by it. Policies constrain what agents may do, the audit log records what they did, and evaluation shows how behaviour changed between versions. This section maps those mechanisms to the EU AI Act, the General Data Protection Regulation (GDPR) and the Swiss Federal Act on Data Protection (nFADP). Source: https://aeterion.tech/en/docs/governance-and-compliance Last updated: 2026-09-20 ## Evidence produced by the runtime - Records of automated decisions with inputs, outputs and the model version used. - Human oversight records: who approved what, when, and with which amendment. - Policy change history, including who activated a control in which environment. - Evaluation results per process version, showing behaviour changes over time. ## Mapping to obligations - **EU AI Act** — Human oversight, logging, transparency of automated decisions and technical documentation of the deployed system. - **GDPR** — Lawful processing boundaries, data minimisation through field policies, and records of processing activities. - **Swiss nFADP** — Processing within Swiss residency boundaries and disclosure of automated individual decisions. - **ISO/IEC 27001 and 42001** — ÆTERION is preparing for certification against both standards; no certification is held today. ## Division of responsibility ÆTERION supplies the software, its controls and the evidence it produces. The customer decides which processes are automated, which thresholds apply and who approves escalations. Regulatory classification of a use case remains with the organisation deploying it. > **Certification status** — ISO/IEC 27001 and ISO/IEC 42001 are in preparation and SOC 2 Type II is planned. The Trust Center states the current status; no certification is claimed before it is issued. --- # Changelog > This changelog records product releases that change documented behaviour of BRAIAN: new platform capabilities, policy types, connectors and command line changes. Entries are dated, versioned and written so an operator can decide whether a release requires action before upgrading a production environment. Source: https://aeterion.tech/en/docs/changelog Last updated: 2026-09-20 ## 2026-09 — Policy impact testing - braian policy test replays a policy over recorded runs and reports allowed, escalated and denied calls before activation. - Policy activation is recorded per environment with actor, version and timestamp. - Field-level masking is available for HRIS and database connections. ## 2026-07 — Environment promotion - Process versions are promoted between sandbox, staging and production without carrying data or credentials. - Runs are permanently bound to the definition version active at start time. - Audit export supports JSON and streaming to an external system. ## 2026-05 — Escalation routing - Escalations are routed to roles rather than individuals, with configurable timeout behaviour. - Approvals can be given in the console, by email or in Slack, and are recorded identically. - Escalation rate per step is available as an operational metric.