Agent permissions for your team's files.

Agent permissions for the files your team shares. Permissions attach to folders and inherit down the tree. Agents reach it over MCP and see only what the principal behind them may see.

No. Signing in creates a personal workspace. Creating an organization is optional.

Name it and add files in one flow. A folder comes into existence with its first content. Permissions, history and audit all scope to the folder you are standing in.

Folders and files, nesting like a filesystem. Underneath is a content-addressed git object model in Postgres. Every document carries its own line of versions, and every past permission state is queryable.

Anything that speaks MCP. The console has ready-made steps for nine clients: Claude Code, Claude Desktop, Cursor, the two Codex surfaces, ChatGPT, Gemini CLI, VS Code and Cline. Every other client takes the same endpoint.

The plugin, where there is one. It registers the same server and brings the skills that explain what you can reach, plus the slash commands on Claude Code, so it is one step instead of two. Claude Code, Claude Desktop, the Codex CLI and the Codex app can install it. Every other client adds the server directly, and connects exactly the same way.

Not for yourself. A person signs in through the browser over OAuth. Tokens are for agents your application runs, which have no browser to redirect.

List folders, list and read documents, and search everything it can reach. It writes and edits where it holds an editor grant.

list_org_folders · list_org_docs · read_org_doc · search_org_knowledge · write_org_doc · edit_org_doc · delete_org_doc · brief_me

By meaning where a vector index exists, and by text where it does not. The authorization filter runs in the SQL WHERE clause before ranking. Content you cannot reach never enters the candidate pool.

Write to contact@agentlefs.com with your client, what you ran and what came back. A person reads every message.

Yes. An agent claims a document or one of its sections before it edits, and another agent's write into that claim is refused until the claim is released or expires. Agents ask each other things with typed messages, addressed by name or by what an agent is responsible for. When two agents edit the same document at once, one edit lands and the other is refused and told to re-read.

claim · message · edit_org_doc expected_commit

Both, over the same authorization. It covers documents, folders, renames, moves, search and grants. The OpenAPI spec is served from the API itself.

GET /v1/documents · POST /v1/grants · GET /v1/openapi.yaml

Yes, and that is what the REST API is for. Give each of your users a principal, and every read you make for them returns only what they may see. Your own code manages access with POST and DELETE on /v1/grants.

No. A path they cannot reach returns 404, and so does a path that does not exist. The two are deliberately the same status and the same body.

NOT_FOUND · 404 · absent, OR present and not yours

No, /v1 refuses a token minted for MCP. Mint a separate key for your application code.

A create carries an Idempotency-Key, so a retried request is the same request. An update carries If-Match, so a stale write returns 409 instead of overwriting a concurrent edit.

Idempotency-Key · If-Match

Three rungs, each containing the one below: reader, editor, approver. An approver can share and manage access, and edit, at or below where it holds the grant. There is no fourth level.

No. A credential authenticates a principal. What that principal can do in a folder is derived at request time from its live grants.

credential → principal → groups → grants → files

Nothing that reveals the document exists. Denied content is never returned, listed, matched or counted. From outside, refused and absent look identical.

Yes. A folder grant reaches content added after it. A grant on a single file reaches only that file.

Yes, and that is the normal case. Each grant is independent, so one folder serves an approver, an editor, a reader and an agent at once. A grant on a path inside the folder can only widen what the folder already gives.

No. Access only ever adds, so there is no deny rule and no exception list. Keep the sensitive path outside every broad grant instead, which is why a grant's scope is a path rather than a folder. A subtractive rule was removed on purpose: it broke the monotonicity the read filter depends on.

Yes, and a group nests at any depth. A grant to a group reaches every current member, so adding someone to the group is how you grant them. Removing them from the group is how you revoke.

Yes, both are principals and take the same grants. The only difference is how they authenticate: a person signs in through the browser, and an agent carries a minted token. Nothing in the authorization model knows which is which.

No. Labels drive search and filtering only. Access comes from grants on the file and the folders above it.

Yes. Ask it, and it calls who_can_read, which lists the people and groups that reach a folder or document, directly or by inheritance. It names people and never shows their content. It only answers for something the asker can already reach.

who_can_read

No. Sharing reaches members of your organization. Invite the person to the organization first, then share with them.

Yes, if the address is the one they sign in with and they are a member here. It becomes the same grant as picking them from the list.

Yes. The share form shows what is in it as you can see it. It also says how many files are withheld from you.

Yes. The editor is live, and an agent's write arrives in the page you are reading without a reload. Every write is still its own version, so you can see exactly what the agent changed and restore an earlier one.

Text and markdown documents, and binary files. Documents get a collaborative editor and their own version history. A dragged-in directory lands as one commit.

Every document keeps its own line of versions, and editing one never rewrites another. History opens from the editor and diffs a version against the one before it. Restore this version puts that text back as the newest version.

The agent's write becomes a version of its own, and the version before it is still there. Open the document's history and restore the older one. The audit trail names which principal made each write. Restoring is a console action today, so an agent cannot undo its own.

A connector mirrors a repository or a Drive folder into a folder of its own, created where you add it, and keeps it current. That folder is read-only here because upstream owns it. Stored credentials are encrypted and never returned to the console.

No, content is live the moment it lands. Uploading grants you the file, and a connector grants the readers you chose at install. Nobody else reaches it until you widen that.

Yes. The REST API reads any document you can reach.

Two independent walls. Postgres row-level security separates organizations. A relationship-based authorization graph decides who reaches what inside one.

Every retrieval, navigation, write, grant, token mint and policy change, including the ones that were refused. Each record carries a hash of the one before it. A removed entry breaks the chain.

record_hash = sha256(payload + prev)

Immediately. Revoking a token or a grant is a database change, and the next request sees it. There is no cache to wait out and nothing to re-mint. Someone with the document already open in the editor loses it too.

Revoke their grants and their tokens, and the next request sees it. Their principal stays, because the audit trail refers to it and a deleted principal would leave unattributable records. Content they wrote stays where it is, under its own history.

No. Not our models and not anyone else's, and your content is never included in a training set. agentleFS makes no call to any model at all. Search is indexed on our own systems with a local algorithm, so building the index sends your content nowhere.

The answering happens in the client you connect rather than here. We serve that client the documents you have given it access to, and it decides which model reads them. Point it at a model running on your own machine and no model provider is in the path.

Yes. Deleting a document hides it everywhere and keeps it recoverable by you. Erasing one destroys its content, its history, its comments and its name, and nothing brings it back. An approver of the document does both from the console.

Write to the address on the privacy page and we remove it. There is no self-service control for a whole organization or a whole folder yet. We would rather say that than point you at a button that does not exist.

At /privacy, linked from the footer of every public page. It carries the long version of the model-use answer above, what we store, and how to get it deleted.

/privacy

Yes, and that is the intended shape for anything unattended. Give it its own principal and grant it only the folders it needs. Mint its token with an expiry.

admin mint-token --principal=<id> --roles=<subset> --ttl=<secs>