How to let your AI agent run your social media without giving it your passwords

You have an agent that writes well. It knows your codebase, it drafts your commit messages, and when you ask it for a launch post it produces something usable. So you copy the text, open a browser tab, paste it into X, and do the same for LinkedIn.

That copy and paste is the whole problem. The writing was never the bottleneck.

The obvious fix is to give the agent your accounts. Install a social MCP server, paste in your API credentials, and let it post. Plenty of people are doing exactly that right now, and the tooling appeared quickly: one vendor surveying the space in 2026 called it "small, early, and honestly a bit messy". Most of these servers work the same way, by calling the platform APIs using credentials you configure.

You have handed a non-deterministic system, one that reads web pages and emails and pull request comments, the ability to speak publicly as you.

The failure mode is not hypothetical

In 2022 a recruiting company ran a Twitter bot on GPT-3 that posted about remote work. Users worked out they could reply with new instructions. One told it to ignore its previous instructions and take responsibility for the 1986 Challenger disaster, and it did, publicly, from the company account. The bot was pulled.

That was a toy. The current version is not. Security researchers demonstrated this year that OpenAI's Atlas browser agent could be hijacked by hidden instructions planted in an email, causing it to send a resignation letter to the user's boss when it had been asked to draft an out-of-office reply. The user never saw the instruction.

An agent with posting rights is a system where any text it reads is potentially an instruction. Your competitor's blog post. A GitHub issue. A reply on the thread it is monitoring. You do not have to believe your agent is malicious to believe this is a bad idea, and the industry has already reached that conclusion: human review of agent output has moved from a design preference to something auditors and insurers expect.

Separate what it says from what it can do

The useful reframe is that "let my agent handle social" is two independent problems, and people conflate them.

The first is knowing what to say and how to say it. That is a context problem, and it is solvable with no security implications at all.

The second is being allowed to say it. That is an authorization problem, and it should never be solved by giving an agent a password.

Solve them separately and this stops being frightening.

1. Give it your voice as decisions, not adjectives

"Write in my voice" fails because a model cannot act on it. Voice decomposes into concrete choices: whether you use contractions, whether you capitalize the first word of a post, how long your sentences run, the twenty words you always reach for, the ones you would never type. We wrote about how to break your voice down into those decisions in more detail.

The difference between an agent that has those decisions and one that is guessing is not subtle:

Same input. The second is what happens when the agent has your decisions instead of inferring them.

2. Give it something to talk about

An agent with your voice and no material writes fluent posts about nothing. It needs a source of truth for what is worth saying this week, and the good sources are already lying around: your shipped work, your changelog, your docs, the topics you have decided you care about.

Two of them are worth wiring up permanently rather than feeding by hand.

Your own writing. Point a pipeline at your blog's RSS feed and every post you publish becomes several social posts, in your voice, sized for each platform. This post you are reading was chopped up and distributed that way. See content redistribution for how the mapping works.

What is happening in your space. Give it the feeds you already read, and let it surface the few stories worth a reaction, scored against your brand context rather than a keyword match. That is news monitoring and reactive content.

Without one of these, you are still the bottleneck, just at a different step.

3. Do not give it credentials. Give it a scoped key.

The shape that makes the rest of this safe: your agent should not hold tokens for X and LinkedIn at all. It should hold one key to a service that holds those tokens on your behalf, and that key should carry only the permissions you granted it.

What you are describing at that point is a social scheduling service with an agent-facing interface. It owns the platform connections, the posting queue, the retry logic and the review surface. Your agent talks to it instead of to X, and the blast radius of a confused or hijacked agent drops to whatever that one key was allowed to do.

The properties worth insisting on:

• Scoped. A read key can list your drafts and inspect your brand profile and is unable to publish, because the write operations refuse it.
• Named and separate. One key per agent, so you can see what each one did and revoke one without breaking the others.
• Revocable instantly. One click, not "rotate the password everywhere".
• Attributable. Every action records which key performed it, so "what did this integration do" has an answer.

A prompt injection against an agent holding a read-scoped key produces nothing. There is no capability to hijack.

4. Keep a human gate until you are bored of approving

Even with scoped keys, the agent can still write something you would not have written. That is a content problem rather than a security one, and the answer is a review step you remove when you stop finding anything to correct.

Draft-first is the sane default for anything that speaks publicly as you. Useful guards to have on that queue:

• an approval mode you control, so nothing publishes unread unless you decide otherwise
• sensitivity rules that hold posts touching topics you have flagged
• per-channel length limits enforced before anything goes out, since what fits on LinkedIn does not fit on X

Once your correction rate is boring, loosen it.

Where Borker fits

This is the shape we built, and the reason we can write about it with a straight face.

Borker holds the channel connections, so your agent never sees a platform credential. It connects to a single MCP endpoint with a key you issue and can revoke:

claude mcp add --transport http borker https://borker.xyz/api/v1/mcp \
  --header "Authorization: Bearer <your agent key>"

Your agent then discovers tools for reading your channels, brand voice, schedule and pipeline, and for drafting, approving and scheduling content. It reads the voice decisions you configured once, so it writes as you without you re-explaining yourself every session. Everything it produces lands in your normal review queue under the guards above.

The part that matters for this article: the cheapest plan that does all of it is $9 a month, because you bring your own Anthropic key and pay the model provider directly. For that you get X, LinkedIn, Farcaster and Paragraph (three channels included), unlimited generation on your own key, daily workflows that keep a schedule without you thinking about it, routing rules deciding what goes where and in what format, news-reactive posts, RSS redistribution, and the agent interface described above. Full breakdown on the plan comparison page.

What you would be building instead

If you would rather build this yourself, it is worth knowing the actual shape of the work, because the first API call is the easy part. As one integration guide puts it, the hard parts are "the repeated platform-specific chores around OAuth, token refresh, rate-limit handling, payload validation, retries, and queue durability".

Concretely, in 2026:

• X moved to pay-per-use pricing: roughly $0.01 per post and $0.005 per read, and about $0.20 for a post containing a link. You will want per-post cost accounting, because link posts cost twenty times a plain one. (Borker meters this per post and shows the balance on the page, rather than burying a surcharge: how URL credits work.)
• LinkedIn access tokens expire after 60 days, and the programmatic refresh flow is limited to approved Marketing Developer Platform partners. Outside that programme your automation breaks every two months until someone re-authorizes by hand. (Borker holds and refreshes the connection: connecting accounts.)
• Each platform has its own auth model, payload shape, media upload flow and rate limits, and they change without asking you. (Borker keeps one interface across all four: channels.)

Then you still need the parts that are not the API: a queue that survives a restart, a retry policy that does not double-post, a review surface, and an audit trail of what your agent did.

None of that is impossible. It is a different project from the one you meant to work on, it never finishes because the platforms keep moving, and it sits directly on top of how the public sees you. That is an unusual place to run software you maintain in your spare time.

The actual point

The instinct that giving an agent your passwords feels wrong is correct, and the answer is not to keep copying and pasting forever.

Give the agent the context to sound like you, and an interface that limits what it can do to exactly what you meant. Let something else own the credentials, the refresh tokens and the retry logic. Then the question of whether your agent might say something you did not sanction stops depending on how well-behaved the model is today.

References

• Borker MCP setup and the API reference
• Agent keys and scopes
• What shipped in the agent release
• Building an AI that writes in your voice