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 organization argument is ignored.
  • OAuth: acts on your active organization unless a call passes an organization slug you are a member of. A slug you are not a member of is a FORBIDDEN refusal, 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_publish is 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.