Loading...
Trust · security
Runs on your permissions.Keeps every change on record.Runs on yourpermissions.Keeps everychange on record.
The agent reads and writes company data with the caller's permissions, and every change goes into an audit log that cannot be edited. Data is encrypted, stored in US data centers, and never used for training.
It finishes the job
The agent reads the purchase order and posts the sales order, then issues the invoice and files the return itself.
No new permissions
The agent uses the caller's edit permissions as they are, and data outside them cannot be queried at all.
Every action is logged
What the agent read and wrote, and what a person changed, go into an audit log that cannot be edited.
Never used for training
Company data is never used to train models, and nothing stays with the model provider after processing.
How work moves
The agent does the work while the system enforces permissions and keeps the log
Permission checks and logging run at every step, and neither can be switched off.
- OutsideIntakePOs · bills · applications
- AgentReadSource to system fields
- SystemPermissionsChecked before every write
- AgentPostSales order · journal entry
- SystemLogOne line per action
- AgentDeliverInvoice issued · return filed
Screens
Approvals, logs, and permissions in one place
Records the agent posted, the audit log, and the permission table sit on one screen, with the agent's values marked apart from a person's.
The agent reads the purchase order, fills in customer, items, price, and due date, and posts the sales order, flagging any field the PO leaves out.
The source the agent read, the record it wrote, and the field a person edited each get a timestamped line, and an administrator exports any date range as CSV.
When Sales calls the agent it sees what Sales sees, and payroll or journals outside that role never show up on its screen.
Details
Execution, permissions, data, models, operations
Scope of execution
The agent finishes the work itself, including invoices and filings.
Creates and edits records directly
The agent reads the source and writes sales orders, journals, and HR records straight into company data, with the source file attached to every record.
Rollback is one step
A record the agent wrote is reverted from its line in the audit log, and the reversal is logged too.
Issues invoices and files returns
The agent builds EDI invoices and sales tax returns and submits them through SPS Commerce and Avalara, and the acceptance result comes back onto the record.
Fields missing from the source are flagged
A field missing from the source, or one that reads two ways, is flagged, and a value filled from the contract or the history carries its origin.
Scheduled runs finish the job
Anomaly detection and continuous reconciliation run on a schedule, and unmatched lines are flagged with the cause.
Scope is set by your company
Which documents the agent handles, and how far, is set at onboarding to match your policy, and later changes are made by an administrator in one place.
Permissions and audit log
The agent acts with the caller's permissions, and every action goes into the audit log.
Role-based access control (RBAC)
The org chart and roles are the permissions, and people, the agent, and apps built with App Builder use the same permission table.
The agent runs with the caller's permissions
The agent has no administrator permissions of its own, so called by Sales it runs as Sales and called by Accounting it runs as Accounting.
Every agent action is recorded
What it read, what it wrote, and which request started it get one entry each, with any edit a person made recorded alongside.
The audit log cannot be edited, and it can be exported
Entries are append-only, and an administrator can export a date range or a user as CSV.
Departures and transfers are handled in one place
When an account closes the agent and the apps close with it, and when someone changes departments their permissions change on the spot.
No permissions to design per app
Dashboards and admin panels built with App Builder inherit the company's permission rules, so when the builder says "Sales only", that is the whole setup.
Data handling
Company data is kept apart per company, encrypted, in US data centers.
Separate storage per company
Sales, inventory, accounting, and HR data are stored per company and never mixed with another company's.
Encrypted at rest and in transit
Stored data is encrypted, and traffic between the browser, the server, and the model provider uses TLS 1.2 or higher.
Stored in US data centers
Data is stored in US cloud data centers, and a company that needs a different region chooses it at onboarding.
Backup and recovery
Data is backed up on a regular schedule, and the frequency, retention period, and recovery time objective are written into the contract.
Retention and deletion
Data is kept for the term of the contract, and when it ends you download your data and we delete it on the timing written into the contract.
Operator access is logged too
Our operations staff cannot see your data by default, and when an incident calls for access we ask for your consent first and log that access as well.
Models and AI usage
Models read the source and produce the document, and they are never trained on your data.
Never used for training
Company data, the records the agent wrote, and the edits people made are never used to train models.
Nothing stays with the model provider
We hold Zero Data Retention (ZDR) agreements with model providers such as Anthropic and OpenAI, so data is discarded as soon as the model finishes processing.
Only what the task needs leaves the system
The agent sends the model only the source document and the fields needed for one record, never the company's data as a whole.
Requests and results are logged
Requests made to the agent and the results it produced stay in your company data, and an administrator can see who asked for what.
The system does the writing
The model reads the source and decides the values, and the system checks permissions, writes them, and attaches the source to every line.
Model providers can be changed
Which model providers to use is decided at onboarding, and a company that must exclude a specific provider is set up that way.
Operations and access control
Sign-in, network, change, and incident handling follow your policy.
SSO
People sign in with the company account you already use, connected over SAML or OIDC, with no separate accounts created.
Two-factor authentication
Accounts that do not use SSO can be required to use two-factor authentication.
IP allowlist
Access can be limited to your office and VPN IP addresses, and an administrator manages the allowlist.
Change management
Tax and form updates are applied by us with notice before they go live, and company-specific changes are made by your staff in App Builder and logged as well.
Incident response
Outages and security incidents are reported to you through a defined procedure, with the scope, the fix, and the prevention measures in writing.
Uptime and maintenance
The uptime target and maintenance windows are written into the contract, and maintenance happens outside business hours with advance notice.
Security review
Security review documents
They go out on request, and a security questionnaire is answered item by item.
- Security overview (architecture, encryption, access control)
- Data processing agreement (DPA)
- Zero Data Retention (ZDR) agreements with model providers
- Audit log specification and export format
- Backup, recovery, retention, and deletion procedures
- Incident response procedure
- Subprocessor list (cloud, model providers)
- On-premises and dedicated region options
Frequently asked questions
Bring your security lead to the demo.
We walk through the permissions model and the audit log on your own org chart.