Access control
Who a run acts as
Every Autessa tool, agent, multi-agent and script runs as the person who started it, and those limits follow the run into sub-agents, tools, scripts and analytics queries. Nothing a run passes along, such as environment variables, arguments or tool inputs, can change who it runs as, so automation can never reach more than the person behind it.
The problem
What problem does it solve?
In many platforms automation runs as a powerful service account, so anyone who can trigger it borrows its access. That turns every workflow into a possible privilege escalation.
How it works
- 1
A person starts a run
From the builder, the CLI or a team-only app, the run acts as that person, seeing exactly the rows and columns they see.
- 2
Keys and visitors are bounded
A run started by an API key has the key’s limits, never more than its owner. A visitor of a public or sign-in app runs within the app’s permissions.
- 3
Background runs have an owner
Triggers, scheduled jobs and webhook handlers run as the person who set them up. If that person leaves, the run fails with a message saying so.
- 4
Calls are checked
Calling another tool or agent with tools.invokeById or agents.invoke needs at least READ on it for the person the run acts as.
Every option
Who a run acts as: settings and options
| Setting | What it does |
|---|---|
| Run as: Owner | toolConfig.runAs: "OWNER". Only simple AutessaDB data tools with a fixed table and columns. |
| Only callable from my other tools | toolConfig.invokableBy: "OWNER_TOOLS". Nobody can call the tool directly. |
| Turns itself off | When anyone else edits, publishes or rolls back the tool, when ownership moves, or when it is installed from a package. |
| Run history visibility | Each run is visible to the person it ran as, the resource’s Admins and company Admins. |
Permissions
Who can do what?
| Who | What they can do |
|---|---|
| Tool owner | Turn on Run as owner. Nobody else can. |
| API key and app-visitor runs | Cannot use the CLI tool. |
| Company Admins | See all run history. |
What to know
- Scripts, CLI tools, analytics queries, connectors and any tool that takes a table or SQL from its caller can never run as their owner.
- Prefer running as the caller; use Run as owner only for a narrow data tool.
Connections
How Who a run acts as connects to the rest of Autessa
Reports, policies and security questionnaires are on the Autessa Trust Center.
FAQ
Who a run acts as: questions
Can a tool run with more access than the person using it?
Only a simple data tool that its owner explicitly sets to Run as owner, limited to the one table it is configured for. It turns itself off if anyone else changes it.
Who does a scheduled job run as?
The person who set it up. If they are no longer a member, the run fails and says so.
Who can see a tool’s history?
The person each run acted as, the tool’s Admins and company Admins.
Get started with Who a run acts as
Tools, agents, multi-agents and scripts run as the person who started them, into every sub-agent and tool they call, and nothing a run passes along can change who it runs as.
Reports, policies and questionnaires live on the Autessa Trust Center.
100% customizable, code and all
Make Autessa Security & Compliance fully your own.
Use it out of the box, then change anything. Ask Autobot, Autessa’s AI builder, for a new field, screen, report, workflow or agent and it builds it into your copy of the app. Or open the code and edit it yourself. Nothing is locked: the app, its data and its code are yours.
Start free and make it yours