Appearance
AI Agents & MCP
SeyalRun can be driven by software — a script, a CI job, or an AI agent — and not just by a person in the console. Both get in the same way, through the same gate, into the same audit log.
There are two doors, and they lead to the same room:
| Door | For | What it is |
|---|---|---|
| REST API + PAT | Scripts, CI, anything that speaks HTTP | The same /api/v1/... API the console uses, authenticated with a scoped Personal Access Token. |
| MCP server | AI agents and MCP clients | SeyalRun's capabilities published as Model Context Protocol tools and resources, authenticated with the same PAT. |
The MCP server is not a second API. Every tool it exposes is a thin wrapper that forwards the agent's token to api-gateway and returns the answer — so an agent gets exactly the access a script with that same token would get, no more.
The rule that makes this safe
Effective access = token scopes ∩ owner's role ∩ per-host authorization.
Three independent gates, all of which must say yes:
- Scopes — what this specific token was issued for (
inventory:read,automation:run, …). Enforced per request atapi-gateway. - Role — the RBAC permissions of the human who created the token. A token cannot exceed its owner; if you lose admin, your tokens lose admin.
- Authorization — the per-host, per-action grant that governs whether anyone may touch that host. Agents are not exempt from it.
Scopes only ever narrow. There is no scope that widens access, and no way for an agent to acquire one at runtime.
Two hard lines
These are not configuration. They are refused at token issuance and unsatisfiable at the gateway, so there is no deployment in which they are on:
- An agent can never read a credential.
credentials:*is not grantable to a token. An agent holdingsessions:opencan use a credential to reach a host —terminal-serviceunwraps the secret with its own service identity — but the token never sees the secret itself. - An agent can never administer identity or access.
admin:*(users, roles, authorizations, token issuance, settings) is not grantable either. An agent cannot grant itself a host, promote its owner, or mint another token.
A third line is a design choice rather than a hard block: there is no "run an arbitrary command over SSH" tool. The agent primitive for changing a host is run_automation — an admin-approved job template with server-filtered parameters, recorded like any other job. If you want an agent to be able to do a thing, make that thing a template.
Everything an agent does is audited
Because agent calls land on api-gateway like any other call, each one writes the same row into the same tamper-evident audit chain a console click would — with the token's owner as the actor. "Which of this user's actions were done by an agent" is answerable after the fact, not something you have to instrument up front.
Where to go next
- API Tokens & Scopes — issuing a token, the scope catalog, and how enforcement works.
- MCP Server — connecting an MCP client, the auth handshake, and deployment.
- Tools & Resources — the full reference for every tool.