Agents as actors
An agent acts under its own identity, within the access of the person it works for, and every write and every AI dollar it spends is attributed to it.
An agent in Standards is not a feature of the person who runs it: it is an actor of the workspace, next to its members, its API keys and the platform itself. It has its own identity and its own role, what it writes is recorded as its own, and what it spends is attributed. This page describes what that looks like from the outside.
One identity per agent
Every agent has its own actor, of type agent. A turn in a conversation, a run started with Run or POST /agents/:id/run, and a run a trigger fires all act as that agent; a sub-agent acts as the agent that spawned it. There are two exceptions, whose turns run as the person they act for, so what they write and spend reads as theirs, user: a conversation with no agent, and a turn on an environment of a private agent run by someone it is shared with rather than its owner.
The workspace's actors have four types:
| Type | Who |
|---|---|
user | A member. |
agent | An agent. |
api_key | An API key. |
system | The platform's own work. |
What an agent writes is recorded as the agent
Every entry of the activity log carries the actorType of whoever performed it, read from that actor when the entry is written. A record an agent created or changed shows actorType: "agent", never the member who started it:
curl "https://api.standards.new/v1/audit?resourceType=record&limit=20" \
-H "Authorization: Bearer stndrds_your_api_key"GET /audit needs audit:read. A record's own history, GET /audit/records/:recordId, needs no grant beyond being able to read the record. When an agent worked for a member, its entries also name that member, so the activity tab shows both: the agent that acted, and for whom.
What an agent may do
An agent's own role — agent_default unless you assign another — is intersected with the roles of the person it acts for. A tool call that intersection does not cover is refused to the agent, which reads the refusal and carries on. Who that person is — in a conversation, a run, a trigger, a schedule or a sub-agent — and how a built-in agent started by its own trigger or schedule acts with its own role alone, is listed in Roles and permissions.
An agent outside Standards
An agent that runs elsewhere — a script, a coding assistant, an MCP client — reaches the workspace through an API key, and the key is its actor, of type api_key. Bound it with a role that grants only what it needs:
standards keys create --name ci-bot --workspace --role ci --yes--workspace makes a key that acts with its role alone; --role <name> binds that role instead of member, and is refused unless your own access covers everything the role grants. Without --workspace the key is personal: it acts within your access, never beyond it, and narrows when you are demoted. See Workspaces and API keys.
What an agent reads
An agent reads records the way the person it works for does. In your conversation, or in a run you started, it reads the workspace's records and your private ones — including those shared with you — within its role. It never reads another member's private records unless they are shared with you.
An agent working with no member behind it, such as a run a trigger fired, reads as itself: workspace records, and none of a member's private records, not even its trigger author's. What it may do is still bounded by its trigger author's access, as above.
What an agent spends
Every paid AI call an agent makes is journaled under the agent. GET /ai/usage?scope=workspace groups the spend by the member billed, and each row's actorType says what that row is:
- an agent working for you is billed to you: its spend is folded into your row,
actorType: "user"; - an agent working with no member behind it is billed to itself, in a row of its own,
actorType: "agent".
scope=me returns your own usage with the agents that worked for you included. The report, its window and its cost fields are described in Usage and limits.
Next steps
- Agents and routines — define an agent, run it, and arm its triggers.
- Roles and permissions — the
agent_defaultrole and how an agent's access is intersected. - Usage and limits — the usage report, the AI credit state and the quotas.
- Book a demo