# Security & Deployment — OneDroid Synapse > How OneDroid Synapse is deployed, what it can and cannot see, how credentials are held, and an honest statement of our current compliance posture. Canonical: https://onedroid.ai/security OneDroid Security & deployment # What we can see, and what we can't. Written for the person who has to sign off on this. It states the deployment options, where credentials live, what OneDroid can observe in each model, and what we have not yet done. Send it to your security reviewer. OneDroid Argus ## Where the verifier runs, and where it never does. OneDroid Argus exercises a running system, so it is worth being exact about which one. The Argus runner is for development and sandbox environments only. It never runs against production, it is never given live credentials, and its database access is read-only — it reads state to check what a scenario did, it does not write to your data. The runner executes inside your own environment next to the system under test, and it is open source under Apache-2.0, so what it does is readable rather than asserted. What leaves your boundary is the evidence the control plane needs to adjudicate a verdict, not your data. Deployment topologies ## Three shapes, decreasing exposure. ### Hosted OneDroid Synapse runs on OneDroid infrastructure. Fastest to start. We operate the gateway, hold encrypted credentials, and can see tool-call metadata. ### Hosted + your database The gateway is ours; OneDroid Engram's data lives in a Postgres you own and control. Documents, embeddings, history and permissions never leave your database. ### Self-hosted (enterprise) OneDroid Synapse runs on your infrastructure, cloud or on-premises. Credentials and the event log stay inside your boundary. We can see nothing at runtime. Data visibility ## What OneDroid can see, per model. This is the question every security review asks, so here it is directly rather than implied. ### Hosted Tool-call metadata — which agent called which tool, on which connection, when, and whether it was allowed. Credentials are held encrypted so the gateway can present them upstream. Tool payloads pass through the gateway in order to be routed. ### Bring-your-own database Everything above, minus your OneDroid Engram content: documents, chunks, embeddings, revision history and permissions are rows in your Postgres. You can read them with SQL and back them up with your own tooling. ### Self-hosted Nothing at runtime. No telemetry path back to us by default. Support is whatever you choose to send us. Access control ## Tool-level access control, and an audit log. AI agent governance means two things: control over what your agents can reach, and an audit log of what they did. OneDroid Synapse enforces both at the gateway, so the policy does not depend on each agent choosing to comply. ### Per-tool toggles Grant or deny individual tools on a connection, not just whole integrations. An agent that should read a board but never delete one is expressible. ### Credential custody Agents never hold long-lived upstream credentials. The gateway holds them and presents them per call, so revocation is one place, not many. ### Append-only audit log Every tool call is written to an event log you can query and export. It is included in the free tier and will not be put behind a paywall. ### Hubs and roles Connections are grouped into hubs with role-based membership, so access is granted to a team boundary rather than pasted into a config file. Authentication ## Standards, not a bespoke scheme. OneDroid Synapse implements OAuth 2.0 authorization-server discovery at `/.well-known/oauth-authorization-server`, dynamic client registration, and the device authorization flow — so MCP clients can authenticate without anyone pasting a long-lived token into a config file. The OneDroid application has completed Google's OAuth application verification, including its branding and app-purpose review, for the Google Workspace connections it offers. Single sign-on. User identity is handled by Clerk, so OneDroid Synapse inherits its enterprise SSO support: SAML 2.0 and OIDC against your own identity provider, including Microsoft Entra ID, Okta and Google Workspace. Enterprise deployments have been integrated with customer-managed identity providers, including organisations running an internal IdP alongside Entra. We name our identity provider deliberately. You are entitled to know which subprocessors sit in your authentication path before you put staff accounts through them, and a security page that hides that is not one you should trust. If your IdP is an unusual one, tell us which and we will confirm it against Clerk's supported list rather than guess. Compliance posture ## Where we actually are. We would rather lose a deal than pass a security review on an implication. ### What is true Credentials are encrypted at rest. Transport is TLS. The event log is append-only and exportable. Self-hosted deployment removes us from the data path entirely. Google OAuth verification is complete. ### What is not yet true We do not hold SOC 2, ISO 27001, or HIPAA attestation today. If a certification is a hard requirement for you, say so early and we will tell you honestly whether the timeline works, rather than discovering it in month three. ### How to verify us Our delivery method — including the gates, the enforcement hooks and the failures that produced them — is public under Apache-2.0. You can read how we work before you trust it. Reporting a vulnerability ## Tell us privately, first. Email michal@onedroid.ai. We reply within one business day, agree a disclosure timeline with you, and credit you unless you would rather we didn't. Please don't open a public issue for anything exploitable. ## Bring us your security review. michal@onedroid.ai Enterprise You'll reach Michal Bacia — the team that builds the product, not a sales queue. We reply within one business day.