Agents

There are two ways an agent reaches Deliverd. An AI tool a person uses — Claude, ChatGPT, Cursor and the like — connects as that person, and can do what they can do. An agent identity is different: an agent in its own right, such as a scheduled job or a pipeline, that acts under its own name and only inside the boundaries you set on Admin → Agents.

Agent identities#

Creating agent identities is included in Business and Enterprise. On other plans the screen still lists any agents the organisation already has, so they can be reviewed and disabled after a downgrade; only creating new ones is refused.

1. 1

   Create the agent

   On Admin → Agents, choose New agent and give it a name people will recognise in the audit log, such as Finance Reporting Agent. Names are unique within the organisation.

2. 2

   Set its publishing boundaries

   Open the agent and choose where it may publish and who it may share with (below). Save the policy.

3. 3

   Decide what it may ask people for

   Switch off anything it should never put in front of a person.

4. 4

   Issue a key

   Choose Issue new key and copy it straight away — it is shown once. Give it to the agent's runtime as its API key.

Publishing boundaries#

An agent's publishing policy works as an allow-list: anything not explicitly allowed is refused, and each refusal is written to the audit log as agent.policy_denied. The checks sit in the publishing service itself, so they apply whether the agent uses the API, the MCP server or a schedule.

Can publish into workspaces

The workspaces where it may create reports. An agent must always publish into one of them.

Can update specific reports

Reports it may publish new versions of, in addition to any report in a workspace it may publish into.

Can share with

Everyone in the organisation, or named workspaces. Sharing with anyone else is refused.

External sharing

Whether it may invite guests and create secure links. Off, it can share only inside the organisation. Separately, an agent can never make a report public; only a person can.

What it may ask for#

Four switches control what the agent may put in front of a person: Publish reports, Ask for approval, Ask for a review and Ask people for information. All four are on until you turn one off, and a change applies to the agent's existing keys at once — there is nothing to reissue. Each change is recorded as agent.permissions_changed.

Which approvals need two people, or who must decide them, is set organisation-wide in Policies; Ethics rules can put a concern in front of the approver. Neither can approve anything on the agent's behalf.

Keys#

• Rotate by issuing a new key, moving the agent onto it, then revoking the old one. Every issue and revoke is audited, and the list shows when each key was last used.
• Revoke a key the moment you think it has leaked. Requests with it are refused from then on.
• Disable agent at the top of the agent's page stops every one of its keys at once, without revoking them, until you enable it again.

Scheduled updates#

An agent can be expected to publish a new version of a living report on a schedule, set on the agent's page. The agent still does the publishing through the API; the schedule records the cadence it should keep. Only enabled schedules count towards your plan, so turning one off frees its place.

The bottom of the agent's page lists its twenty most recent actions from the audit log, refusals included.

Connecting AI tools#

Anyone in the organisation can connect the AI tools they already use from Connect, which has instructions for each tool. Most connect through the MCP server and need no key: the person approves the connection in their browser the first time it is used, and chooses which organisation it is for.

Setting up an agent in code — the SDKs, the REST API, the MCP server and the CLI — is covered in the developer documentation.