Skip to main content

Agents & connected apps

You can connect AI agents and other tools to your DFOS account, so they can work in your spaces on your behalf. This is open to everyone — no waitlist, no approval. A connected agent acts as you, so the whole model rests on connecting only tools you trust.

There are two ways something outside DFOS can reach your account, and they are not equally powerful.

A connected agent — an AI assistant you connect over MCP — acts as you and sees everything you see. That is the powerful one, and the whole of its safety is in who you connect.

Signing in to another app with DFOS is narrower: that app gets only what you explicitly grant on the consent screen, and nothing else. That screen is the authoritative list — it names every single thing the app asked for, one line each, so read it rather than assuming. Some lines are facts about you: your public identity, your profile, your email address, the spaces and groups you belong to. Others let the app act as you inside spaces you name — read the posts and comments you can see there, upvote, or write, edit, and delete your own posts and comments. This is also how a command-line tool or a desktop app asks for access, so a tool on your own machine can hold a narrow grant rather than your whole account.

Connecting an AI agent​

DFOS speaks the Model Context Protocol, so agents like Claude can work with your spaces directly. In Settings → MCP you'll find your connection URL — copy it and paste it into your agent's connector settings.

When the agent first connects, DFOS shows you a consent screen with the account it's connecting as, and nothing is connected until you approve. The agent signs in as you the same way you do — there's no password to hand over and no separate key to manage.

What a connected agent can do​

A connected agent works as you: it can do the everyday things you can do in your spaces, and it can't do anything you couldn't. In broad strokes, that means it can:

  • Read what you can read — your spaces, posts, chat and direct messages, notifications, and members, all scoped to what you already have access to.
  • Post and comment in the spaces you're in, and attach media.
  • Edit and delete your own posts and comments, and delete your own messages.
  • Send messages, in space chat and in direct messages.
  • Search across your spaces for people, posts, and conversations.
  • Join and take everyday actions — join a space, follow someone, react, bookmark, and the like.
  • Read these docs, so it can look up how something on DFOS works before it acts.

It's your account in an agent's hands. It sees what you see — including your private messages — and acts under your name, so treat connecting an agent like handing someone your keys. It can remove things as well as add them.

Tools and scripts of your own​

A tool you run yourself — a command-line tool, an agent you wrote, a desktop app — has the same two doors everyone else does, plus a third that skips DFOS entirely.

  • Connect it over MCP if it should work in your spaces on your behalf, the way an assistant does. Same connection URL, same consent screen, same "acts as you" reach.
  • Have it sign in with DFOS if it needs something specific rather than your whole account. It gets a standing grant covering exactly the lines you approved — and, where those lines reach into spaces, only the spaces you named on the screen. It appears under Settings → Connected apps as Local application, and is revocable there like anything else. That is the narrow door, and it is the right one for most tools. The developer side is Local applications.
  • Point it at the protocol if it should not touch DFOS at all. Your identity is a signed chain published to a public relay; a tool holding a key you control can verify and publish against that directly, with nothing issued here and nothing here to revoke. See Sessions, grants, and keys.

Signing in to another app​

Other apps can offer a "Sign in with DFOS" button. Approving one is a different thing from connecting an agent: the app gets what the consent screen says and no more.

The screen tells you exactly what you're approving. It is a list, one line per thing the app asked for, written by DFOS rather than by the app. An app can ask for several at once, and the screen lists every one of them. The full set of lines an app can ask for, with what each one covers, is in Scopes and credentials.

Four of those lines in particular:

  • Just signing in shares your public identity address and nothing else. Nothing is issued to the app.
  • Your email address is always its own line. An app that asked for your profile does not get your email address unless the screen says so separately.
  • Seeing the spaces and groups you belong to includes private and unlisted ones. Nowhere else does DFOS tell an app those spaces exist; it does here only because you approved that line.
  • A line can let the app act as you — post, comment, or upvote inside a space. It reaches your own posts and comments only: never another member's, and never an announcement, a broadcast, a pin, or a moderation action.

The screen also says where​

Whenever an app asks for something inside a space, the screen also says where, right under what is granted. One of three things:

  • In all your spaces, including ones you join later — which also tells the app which spaces you belong to.
  • In these spaces, naming the ones the app asked for. A space you are not in is shown as a plain identifier and says so.
  • Choose where — a picker over your own spaces, nothing pre-ticked, with the all-spaces option set apart at the bottom. Approve stays unavailable until you choose.

Outside the spaces on that list, an app with a write line can do nothing at all.

Who is asking​

Read the screen carefully, starting with what it leads with.

For an app on the web, that is the app's domain, because a domain is the part an app can't fake. The app's own name is never rendered — a name is a claim, and no string an app wrote about itself appears on the screen. Where the asking identity was actually proven, a View on explorer link accompanies the domain instead — a third party's view of that identity, recomputed in your own browser, rather than the app's account of itself. Under the heading is a short list of what DFOS actually checked, one fact per line, with the thing that was checked named on each. DFOS never vouches for an app either way; it tells you what it confirmed and where confirmation stopped.

For a tool running on your own machine there is no domain, and the screen says Local application with the tool's identity address instead. DFOS checked that the tool holds the key for that identity and tells you so, along with the limit: it can't verify where the software came from. Judge that the way you'd judge any program you installed — a checked key says the same party is asking each time, not that the party is trustworthy.

A local tool that proves no key at all gets a weaker screen: An app on your device, no identity address, one limit row saying nothing about it can be verified, and only the plain identity line available to ask for. Local applications covers both shapes.

Either way, approve only a screen you arrived at by starting a sign-in yourself.

Ending a grant​

A grant stays valid until it's revoked, and revoking it stops the app's access on its very next request. Settings → Connected apps lists every app you've signed in to, what each one can do, and — where a grant reaches into spaces — which spaces it covers. Disconnect a single app there, or disconnect all of them at once. That list covers the grants DFOS issued for you, which is not necessarily every session signed with your identity — see Sessions, grants, and keys.

Two more things worth knowing:

  • Only share your email address with apps you're willing to give it to. It is asked for on its own line for exactly this reason. Revoking later ends the app's access; it doesn't un-share what the app already read.
  • Deleting your DFOS account ends every grant with it. A grant issued by an account that no longer exists authorizes nothing.

If you're building an app that uses this, see Sign in with DFOS — or Local applications if what you're building runs on someone's own machine.

Staying in control​

A few habits keep agent access safe and predictable:

  • Connect tools you trust, and understand their scope. An agent acts as you and can reach everything you can, private messages included. Only connect software you'd trust with that.
  • Give clear intent. An agent does what you ask, so be specific about what you want it to do — and, especially early on, review what it posts, sends, or removes before it acts.
  • Only approve prompts you started. Approve a connection or a sign-in when you're the one who kicked it off. If a consent or device-approval screen appears and you didn't initiate it, don't approve it.
  • Check the list now and then. Settings → Connected apps is the full inventory of standing grants, including any local applications. Anything on it you don't recognize should be disconnected, and disconnecting takes effect on that app's next request.