How to give an AI agent safe access to your social accounts

Agents make mistakes at machine speed. A loop that posts every minute, a prompt that produces something off-brand, or a retry storm against a metered platform can all do damage before you notice. Public posts cannot be unsent, and some platforms bill per post. The goal is not to stop the agent posting; it is to make the worst case small.

If an agent holds an Instagram or X token, anything that can read its context can leak it, and the token can do far more than post. With Socifyr the agent holds one sk_ API key tied to a single workspace, and it targets accounts by slug such as linkedin-mybrand. The platform tokens never leave Socifyr. Rotate a leaked key by creating a new one and deleting the old one; the social accounts do not need to be reconnected.

Use one key per agent or service. If one misbehaves you revoke that key alone, and lastUsedAt on each key helps you find unused ones to delete.

// Needs a dashboard session or an unrestricted key
await socifyr.workspaces.updateApiKey(workspaceId, keyId, {
  dailyPostLimit: 20,
  monthlyXSpendCentsCap: 500, // $5.00
  requireApproval: true,
})

You can also set them in the dashboard on the API Keys page (the shield icon). Guardrails apply only to posts created through that key. The dashboard and human-published content are never affected, and limits are enforced atomically. See X API posting limits and costs for how the spend estimate works.

A key with any guardrail is restricted so it cannot be used to get around its own limits.

• Allowed: create posts (text, photos, video, document, bulk-schedule), read posts, status, analytics and usage, upload and read media, list connections, use the AI caption helpers, and edit, publish, retry, archive, delete or submit only posts that key created.
• Edits are drafts only. Once a post is submitted, approved or scheduled, the key can no longer change it.
• `requireApproval` keys can only submit drafts for approval (POST /content/:id/submit-for-approval). They get 403 on publish, publish-now, approve and reject.
• Everything else returns 403: managing API keys (including its own guardrails), members and invitations, webhooks, workspace settings, connections, approvals and billing.

That includes the reconnect-link endpoint: a guarded key cannot mint a link to re-authorize an account, which keeps a runaway agent away from your connections. Unguarded keys can, but only the workspace owner can approve the link.

1. Create a key for the agent and turn on requireApproval.
2. The agent creates posts as usual, for example with post_text over MCP. They land in pending_approval and nothing publishes.
3. A teammate with post.approve permission reviews and approves them in the dashboard. A rejected post returns to draft and never publishes.

Roles matter here too. Workspace roles are Owner, Admin, Editor and Contributor, and only roles holding the approval permission can release a held post. If you want the agent to propose and a person to decide, this is the setup.

• A dedicated key per agent, named after the agent.
• requireApproval: true for the first weeks, then relax once the output is trusted.
• dailyPostLimit set to a little above the agent's normal volume, so a loop hits a wall quickly.
• A monthlyXSpendCentsCap if the agent posts to X, since X is metered.
• The agent checks its own state: get_usage over MCP or socifyr usage shows usage against plan limits, and listApiKeys() reports xSpendCents and xSpendMonth.
• Prefer the MCP connection over giving the agent a raw HTTP client, so it works through named tools.

1. Create a throwaway key with dailyPostLimit: 1 and post to a low-stakes account such as a private Telegram channel.
2. Send a second post. It should fail with a 403 rather than publish.
3. Create a key with requireApproval: true, post with it, and confirm the post sits in pending_approval until someone approves it.
4. Try an admin action with the guarded key, such as listing API keys. It should return 403.
5. Delete the test keys when you are done.

Doing this once, on purpose, is worth more than reading about it. It also gives you the exact error text your agent will see, so you can make sure its instructions say what to do when it is refused, for example to stop and report instead of retrying.