Actori for AI agents

Actori is a control plane for AI agent actions. An organisation connects its tools to Actori once — GitHub, AWS, Slack, Google Workspace, databases, any HTTP, SSH or MCP tool — and its agents reach them through Actori instead of holding credentials themselves.

Every call is authorized before it runs, from the agent’s identity and roles, the action, its arguments and the organisation’s policies. Some calls are routed to a person for approval. Every decision is recorded with the reasons it was made.

Actori is not a model and not an agent framework. It works with any MCP client: Claude, OpenAI, Cursor, or an agent you build yourself.

• ✓Actori is an MCP server over Streamable HTTP (JSON-RPC 2.0). An administrator creates the agent in the Actori console, and the console shows the endpoint URL for it.
• ✓Two ways to authenticate. A platform that supports OAuth — Claude, Codex and others — signs the person in when it connects; the endpoint publishes standard OAuth metadata, so the client finds the authorization server on its own. A platform that works with an API key — Cursor and others — sends the token issued for the agent in the console as a bearer header. An agent you run yourself presents that token or its signed key.
• ✓Once connected, call tools/list. The tools you see are exactly the actions this agent has been granted; nothing else exists for you.

From nothing to an agent that can call a tool, in a few steps. The console’s Help has the full walkthrough; this is its shape, so an assistant can guide a person through it. Where a step names a menu in another product, that product’s own help is current and this page may lag.

• ✓Sign up at app.actori.ai/signup with Google or GitHub. The profile form asks for an Account title, the name the console shows for the account (changeable later), and an Account ID, its fixed identifier in lowercase letters, digits and hyphens, which appears in sign-in links and cannot be changed. Both are prefilled with default; a person setting up for themselves can keep them. A new account starts on the Free plan with one agent, named default. A 30-day Team trial, no card needed, is one click away under Settings → Plan.
• ✓One agent per platform, all in one role. A new account already has an agent role, default-agent, and the default agent is in it; tools are granted to the role. Under Agents → All Agents, New Agent creates one agent for each platform you connect — one for Claude, one for Codex, one for Cursor — and its Role field puts each in default-agent. Do not share one agent between platforms: the audit log, the approvals and the credentials then say which platform made a call, and revoking one platform does not cut off the others. A second role, under Agents → Roles, is only for giving some platforms a different set of tools.
• ✓On each agent’s page, copy its MCP endpoint — it depends on your organisation, so copy it rather than typing one from memory — and choose how the agent authenticates. Enable OAuth Login is for platforms that sign a person in, such as Claude and Codex; they sign in as the agent’s owner, with the owner’s email. Generate API Token is for platforms that take an API key, such as Cursor, and for a script that holds a credential.
• ✓Claude.ai: Customize → Connectors → + Add → Add custom connector. Paste the endpoint, keep the detected sign-in settings and click Add. On a Team or Enterprise plan an Owner adds it under Organization settings → Connectors, and each member clicks Connect.
• ✓Claude Code: claude mcp add --transport http actori <endpoint>, then /mcp and sign in in the browser.
• ✓Codex CLI: codex mcp add actori --url <endpoint>, then codex mcp login actori. With an API token instead: add --bearer-token-env-var ACTORI_TOKEN and put the token in that variable.
• ✓Cursor, or any platform that takes an API key: put the token in a bearer header. In ~/.cursor/mcp.json: { "mcpServers": { "actori": { "url": "<endpoint>", "headers": { "Authorization": "Bearer <token>" } } } }.
• ✓ChatGPT: needs developer mode, which OpenAI offers on Business, Enterprise and Edu plans (Pro can connect read-only tools). A workspace admin creates the connector under Settings → Apps → Create with the endpoint and OAuth, then scans its tools.
• ✓Connect Actori to itself first: Connectors → Add Connector → Actori. It needs no credential — the agent acts as its owner, with the owner’s permissions — so tick the tools and grant them to default-agent. From then on the assistant can answer from Actori itself: which tools an agent has and why a call was denied, what is waiting for approval and what was decided, recent executions and the audit log, the catalog of connectors, and it can add a connector for you to authorise. The section on managing Actori below says what it may and may not do.
• ✓Connect a tool: Connectors → Add Connector, pick the service, sign in to it or paste its key, tick the tools to add and click Add. The same step asks which agent role may call them and whether the destructive ones need a person’s approval.
• ✓Ask the agent to list its tools. tools/list shows exactly what was granted. A client caches that list, so after a grant disconnect and reconnect the server in the client (Claude Code: /mcp → Reconnect) before asking again.
• ✓Try a call. A read runs at once. A call that needs approval answers pending_approval, the approvers get an email, and the request sits under Pending Approvals in the console until a person decides. The section on approvals below says when that happens and how the agent learns the outcome.

These are the instructions every agent receives from the server when it connects. They hold for every tool.

• ✓The tools listed for you are exactly the actions your agent is authorized to call. The set is per-agent and can change over time — always call tools/list before assuming a tool is available.
• ✓Some calls require human approval: they return a pending/approval status instead of a result. Treat that as “submitted, awaiting a human”, not as a failure, and do not retry it in a loop.
• ✓A denied call is a policy decision — do not retry it or try to route around it. Respect the returned error message.
• ✓Each tool’s own description and input schema come from its underlying connector; follow them for arguments.
• ✓A tool may exist on more than one connector instance (an account, a workspace, an environment). Every call names the instance in _meta.target, from the enum on that tool; match it to what the user asked for, and never pick a production instance unless production was asked for or is clearly the subject. If the instance is ambiguous, ask.

Every tools/call reply carries a status in _meta.status and a plain-language line in its content that says what to do next. _meta.is_terminal says whether the outcome can still change.

• ✓success and failed are final. A failure’s message is the connector’s own; tell the user what it says.
• ✓timeout means the outcome is unknown: the call may have run. Check the target system rather than calling again.
• ✓denied is a final policy decision. Inform the user and suggest they ask an administrator for access.
• ✓not_found means no such tool is granted to you. target_required means the call named no _meta.target; call tools/list again and name one.
• ✓pending_approval carries an approval_request_id. Stop, tell the user a person has to decide, and do not run the steps that depend on it. The built-in check_approval_status tool reads the decision: call it at most once when the user asks, never in a loop — a review can take minutes or days.
• ✓quota_exceeded and billing_restricted are the organisation’s limits, not yours to work around. Tell the user.
• ✓A retry of the same call with the same Idempotency-Key header replays the earlier outcome instead of running the action twice. Use one for any call that must not happen twice.

Approval is a rule on the action, set by a person in the console, not a judgement the server makes per call. The agent sees only its effect.

• ✓Where it comes from. Adding a connector asks what to do with its destructive tools — the ones that delete, send, pay or change state — and the default is approval by the account’s administrators. An administrator can add rules of their own on any action: always, or when the arguments, the time or the agent match a condition. The rule’s reason is readable through the Actori connector (list_action_policies).
• ✓What the agent sees. The call answers pending_approval with an approval_request_id and an execution_id, and the server’s own text says to wait. Nothing has run. Tell the user who has to decide (the reply names the approver role) and stop the steps that depend on the result.
• ✓What the person sees. Every approver gets an email, and the request appears under Pending Approvals in the console with the tool, the arguments and the agent that asked. They approve or reject there, with a comment. A multi-step rule needs each step in turn.
• ✓What happens next. Approved: the action runs then, with the arguments as filed. Rejected: final, with the approver’s reason. The agent reads either through check_approval_status with the id — at most once, when the user asks — and an approved call’s reply carries the action’s result; a rejected one carries the reason. With the Actori connector granted, list_pending_approvals and get_approval show the same without the id.
• ✓A retry does not help. Calling the same tool again files a second request for the approvers to deal with; with the same Idempotency-Key it replays the pending answer instead. Never loop on check_approval_status: a review takes minutes or days and the server rate-limits it.

A script, a cron job or an agent you run yourself talks to the same endpoint as a desktop client, with a token instead of a sign-in. The protocol is plain JSON-RPC 2.0 over HTTPS POST; no SDK is required.

• ✓Create an agent for the script (one per script, as for platforms), open its page, copy the MCP endpoint and click Generate API Token. The token is shown once; keep it in an environment variable, never in the code.
• ✓Every request is a POST to the endpoint with Authorization: Bearer <token> and Content-Type: application/json. The reply is JSON. An initialize call is accepted but not required: the server issues a session id, and a request without one is served.
• ✓List the tools: { "jsonrpc": "2.0", "id": 1, "method": "tools/list" }. Each tool carries its input schema and, under _meta.target, the connector instances it may run on.
• ✓Call one: { "jsonrpc": "2.0", "id": 2, "method": "tools/call", "params": { "name": "<tool>", "arguments": { "<field>": "<value>", "_meta": { "target": "<instance>" } } } }. _meta.target sits inside arguments and is required.
• ✓Read result._meta.status as the Reading a reply section says. A script that may be retried sends an Idempotency-Key header on every tools/call, and on pending_approval records the approval_request_id and exits; a later run checks it once with check_approval_status.
• ✓In the shell: curl -s -X POST "$ACTORI_ENDPOINT" -H "Authorization: Bearer $ACTORI_TOKEN" -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'.

An organisation can connect Actori to itself. An agent granted those tools can read what the console shows — executions, approvals, agents, actions, policies, roles, grants, connectors, the audit log — and can add a connector or sync a connector’s tools. Three rules keep that safe:

• ✓An agent never handles a secret. add_connector refuses credential values; a person enters them, or authorises OAuth, in the console.
• ✓A person grants tools. Adding a connector gives nobody access to it.
• ✓A connector last changed by an agent is flagged in the console, and a person reviews it before authorising it.

• ✓How to set up a specific connector, agent or policy: the step-by-step guides live in the console’s Help, behind sign-in. Send the person there rather than guessing a connector’s configuration.
• ✓What Actori is, how it handles data, and what it costs: the pages linked below.
• ✓Account, plan and billing questions: Settings → Plan in the console, or the contact page.
• ✓Security questions and reports: the security page, and the address on it.