Agent-created tables
When a workflow needs to persist intermediate state, it can create its own managed table — with extra governance to keep the blame chain clear.
Workflows sometimes need to persist intermediate state — a deduplicated entity list, a scoring matrix, a sample of a long-running run. Scrydon supports this through agent-created managed tables, with extra governance to keep the actor chain auditable.
The model
An agent-created table behaves exactly like a user-created table in every respect (lifecycle, classifications, masks, row filters) — with three extra invariants:
| Invariant | Why |
|---|---|
Table name must start with agent_ | Visible in lists, search, and the audit log — you can always tell which tables a workflow created. |
Default classification is confidential | Workflows aren't given a public default. An admin can lower it explicitly. |
| Every row carries actor metadata | actor_type, deployer_user_id, workflow_id, workflow_run_id — the blame chain back to a user. |
User-created tables cannot start with agent_. This split makes "did a human or an agent put this here?" answerable with a glance.
When a workflow can create a table
The workflow must:
- Run for a deployer (the person the workflow or Cortex tool acts for) who is a workspace admin or owner — the same rule as creating a table from the table pages.
- Have an explicit
create-tablestep in its definition — the create isn't implicit. - Pass through the same authorisation check as a user-driven create.
The calling service must hold the managed-table:agent-create capability, and the create is then decided as the deployer's own request would be; the workflow can't escalate beyond what the deployer may do.
Writing rows and deleting tables
The same rule covers writing rows to a table and deleting one, whether a workflow or a Cortex tool does it. Each request is decided as if the person the workflow or tool acts for had made it themselves. A workspace viewer can't write rows, create a table or delete one this way, just as they can't in the table's own pages. The refusal is the same 403 they would get there. A workspace admin or owner can do all three. A member can write to and delete only the tables they own, and can't create one, as in the table's own pages.
Data sources are different. Their rows are written by the platform for the source and don't act for a person, so this check doesn't apply to them.
Actor identity columns
Every row inserted by a workflow carries five extra columns:
| Column | Value |
|---|---|
_actor_type | Always "agent" for these tables |
_actor_run_id | The run ID of the workflow that wrote the row |
_actor_workflow_id | The workflow definition ID |
_actor_deployer_user_id | The user who deployed / owns the workflow |
_actor_inserted_at | UTC timestamp of the write |
These columns are reserved — you can't define your own columns with the leading underscore prefix. They're populated automatically; the workflow doesn't see or set them.
Why the extra columns
A managed table is a long-lived artefact. A workflow that wrote a row last quarter may not exist any more, and the user who triggered the run may have left the org. The actor columns give compliance auditors and incident responders a permanent trail back to the originating context — which workflow definition, which run, which deployer.
Removing or modifying actor columns requires explicit org-owner action.
You can grant a workflow the ability to create tables, but you can't grant a workflow the ability to bypass the agent-creation invariants. A workflow that tries to write to a table with a name that doesn't start with agent_, or that tries to set _actor_type to "user", is rejected by the data plane.
Reading from agent-created tables
Reads follow the same governance as any other managed table. The _actor_* columns are always available to workspace admins; whether workspace members see them depends on the table's mask strategies.
Related
- Managed tables — the base lifecycle.
- Classification & masking — how the
confidentialdefault plays out. - Security → Authorization — the execution grant model that gates these writes.
- Audit logging — every agent create / write is recorded.