Security model
What an agent can reach through MCP and what stops it — one guarded core, tenant isolation, organization scoping, approval gates, and per-organization request budgets.
The short version: an agent is not a privileged client. Every tool call resolves who is calling, which organization they are acting in, and whether that actor may perform the operation — then runs the identical procedure the dashboard runs. There is no agent-only path with weaker checks, because there is no second implementation to be weaker.
One guarded core, five doors
The dashboard, the REST API, this MCP server, the CLI, and the SDK all build the same request context and call the same procedures. Authorization and tenant isolation therefore cannot diverge between a human and an agent: a tool that tried to skip a check would have to skip the procedure, and then it would do nothing at all.
Tenant isolation
Every organization’s data is separated at the database level, and each request runs pinned to one organization. A tool cannot read across that boundary even by asking for another organization’s id — the row simply is not visible to the query.
Which organization a call acts on
- API key: bound to one organization at creation. Calls act there; the
organizationargument is ignored. - OAuth: acts on your active organization unless a call passes an
organizationslug you are a member of. A slug you are not a member of is aFORBIDDENrefusal, not an empty result.
What an agent still cannot do
- Publish past a policy. Organization publishing policy and the approval rule are enforced in
the core, so an agent’s
posts_publishis blocked exactly where a person’s would be — with a message naming the rule. Where approval is required, the post waits for a human decision. - Edit a published post. Published posts are immutable. An agent can create, revise while draft, and retry a failure; it cannot rewrite history.
- Authorize a channel connection. Connecting a social account requires a person to complete the provider’s consent screen in a browser. An agent can mint the consent URL and poll the session, but it never sees the OAuth handshake itself.
- Escalate its own permissions. Membership and roles are not writable from this surface.
Rate and spend limits
Inbound calls are charged against a per-organization request budget. Exceeding it returns
TOO_MANY_REQUESTS — back off and retry rather than looping. AI-assisted actions additionally
draw down the organization’s Ink balance; when it runs out, the tool refuses with an upgrade
message instead of silently doing less. See Pricing for what consumes Ink.
Handling credentials
Treat an Organization API key like a password: it grants everything your role can do in that one
organization. Keep it in your client’s secret store or an environment variable, never in a
committed config file. The CLI’s device login (inklate auth login) exists so a local agent can
hold a credential without a key ever being pasted into a file — and
inklate auth logout revokes it.
If a key leaks, rotate it in the dashboard under Settings → API; the old key stops working immediately.
Auditability
Every write records who did it, through which door, and when. An agent acting on your behalf is
as traceable as a person clicking in the dashboard — see the audit trail at
auditLogsList.
Connect a client
Point Claude Code, Claude Desktop, Cursor, or any MCP client at Inklate's server — with an Organization API key, or through the OAuth 2.1 browser handshake.
Available tools
All 32 tools the Inklate MCP server exposes, grouped by what they act on — organizations, connections, channels, billing, posts, approvals, files, discovery, and metrics.