Agents act. Somebody has to be accountable for it.
Sign in with the directory you already run.
Meshly Build authenticates through OIDC SSO, and your identity provider groups map to roles inside the platform. There is no second user list to provision, review, or forget to deprovision. Three tiers, Admin, Dev Manager and Viewer, decide what a person can reach, and project membership decides which projects they see at all.
- OIDC SSO with group-to-role mapping, so joiners and leavers are handled where you already handle them.
- Three human tiers: Admin, Dev Manager, Viewer. Agents carry their own separate permission tiers.
- Project membership access control. Non-admin users only see the projects they belong to.
- Audit export for compliance reviews.
A person and an agent are not the same principal.
Someone planning in a chat window and an agent executing on a workstation get different tool profiles, on purpose. People read, plan, discuss, capture and approve. Claiming, starting and completing work stays with the agent that is actually doing it. That separation is what makes the audit trail mean something afterwards.
- People get a conversational profile. The execution verbs are not in it.
- Agent permissions are project-scoped: an agent reaches the errors, audit log and labels of its own projects.
- Approving your own agent’s work is a human action, recorded against a human.
OAuth 2.1, and consent that names names.
When you connect Claude Desktop or claude.ai, Meshly Build acts as the authorization server rather than handing out a shared key. You sign in as yourself and carry your own permissions into the conversation. The consent screen names the client, the scopes, the instance and the account before anything is granted, and read-only access is read-only.
- Mandatory PKCE, refresh rotation with reuse detection, revocation, and audience binding.
- Consent names the client, the scopes, the instance and the account before it is granted.
- The token clock runs from last use, so a long-lived connection is still an actively used one.
Limits that hold when nobody is watching.
The question a security reviewer asks about agents is not whether they can be trusted, it is how much damage an untrusted one could do before somebody noticed. Every agent runs inside a spend ceiling, a token ceiling and a task rule, and its output does not reach main without a human gate. Automated review starts in record-only mode, so it writes down a verdict and moves nothing until you decide otherwise.
- Spend and token budgets per agent, plus API key expiry and rate limiting on API keys.
- One active task per agent by default, with stale-task detection for work that stops moving.
- Human approval gates before agent work reaches main, with the rejection reason carried into the next attempt.
- Record only is the default for automated review, so you can watch it agree with you before you let it move anything.
Every action leaves a record you can query.
Task moves, agent actions, approvals and policy gates land in a system audit log with a timeline view. Connector activity is recorded to the same standard: client registration, consent granted and consent denied, token issuance, refresh and revocation, each naming the tenant, the user and the client. Admins can also watch a live agent session directly rather than asking for a screenshot.
- System audit log with timeline view, and audit export for compliance reviews.
- Connector events record consent denied as well as consent granted.
- Live console is admin-only, and streams the real session rather than a summary of it.
One workspace cannot reach into another.
On a shared instance a session is bound to the tenant that issued it, so a credential from one workspace does not become a way into a different one. Dedicated single-tenant instances are available where a shared instance is not acceptable to your review. On the workstation, each agent session writes its config into a user-private directory that is removed when the agent exits.
- Sessions are bound to the issuing tenant on shared instances. Dedicated instances are single tenant.
- Per-session agent config lives in a user-private directory and is removed when the session ends.
- Project environment documentation covers references and non-secret configuration. Secret values are not stored there.
Your code stays where your code already is.
Station runs on each operator’s own workstation and spawns the agent there, so source code is worked on inside your environment rather than uploaded to ours. What reaches Server is the record of the work: tasks, verdicts, decisions, knowledge and audit. Server runs on production-grade Postgres, and where it runs is your decision: most teams let us operate it, and it also runs on your own infrastructure. The air-gapped deployment requires that, because nothing on it reaches us at all.
- Station spawns Claude Code on your workstations. The repository is worked on in place.
- Server holds the record of the work, behind your SSO, scoped by RBAC.
- Deployment is your choice: managed by Meshly, or self-hosted on your own infrastructure.
- Air-gapped deployments are self-hosted by definition. Meshly AI runs local models on the box, and nothing leaves it.
The absent controls, listed by us rather than found by you.
Meshly Build has been through two security audits, each followed by hardening across the API surface. It has not been through a SOC 2 audit and it is not ISO 27001 certified, and we would rather you read that here than discover it three weeks into an evaluation. We are a young company operating a production system, and the honest description of our posture is engineering practice plus external review, not a certificate.
- Two security audits, with the resulting hardening shipped in Server 2.0.0.
- No SOC 2 report. No ISO 27001 certificate. We will say so before you ask.
- If a specific control matters to your review, ask and you will get a direct answer about whether it exists today.
Send us your questionnaire.
If your security review has a form, send it. You will get answers from the people who built the thing, marked clearly where the answer is no. If it raises a control we do not have yet, that is useful to us too.