Data & Security

Data and security: how your information is protected

AOS runs inside founder-led companies, so data handling is built in from the start, not bolted on. The core principle is simple: customer data, secrets, and production access are walled off by default, and the five approval points are the only places they cross. What is walled off by default - Customer data. Identifiable customer information stays inside your workspace. Any move that would put it outside (a vendor integration, an export, a third-party share, or an AI training opt-in) triggers an approval point and waits for you. - Secrets and keys. Credentials are not handed around freely. Integrations are granted deliberately, and the Security & Infra department can inventory keys, set a rotation schedule, and revoke stale or over-scoped ones. - Production access. Code deploys, infrastructure changes, billing rules, and security policy are all production-touching changes. AOS drafts and reviews every one; you flip the switch. We do not train on your data AOS does not retrain models on your data. An AI training opt-in is itself one of the gated "customer data leaving the boundary" decisions, so it cannot happen silently. The evidence trail and audit-trail protection Every artifact, draft, decision, and reviewer is captured in the evidence trail. Editing a logged decision or deleting evidence after the fact is the fifth approval point (rare, and the most important when it fires) so your audit history cannot be quietly rewritten. Security as a standing department Security & Infra is one of the eight departments, not an afterthought. It maintains the threat model and risk register, maps where PII lands, reviews access, triages CVEs in your dependencies, and keeps the evidence trail an auditor would ask for. Every artifact any department produces is also scanned by security as the fourth step of the review loop. Compliance posture AOS is built by Workforce AI Corp, which maintains a SOC 2 report available under NDA. If you need to answer a security questionnaire, the PII flow map and access reviews turn it into a copy job rather than a fire drill. For full details see the privacy policy and security posture pages on installaos.com.

Permissions and access control

AOS gives you fine-grained control over what the agent company can reach. Nothing connects to your real tools, data, or production systems unless you grant it. This article explains how access works and how to keep the blast radius small. Default posture: deny, then grant When your instance is provisioned, integrations are walled off. You connect tools deliberately, so the team can only touch what you have explicitly granted. This is the opposite of a tool that asks for broad access on day one and hopes you click yes. A fresh instance can think, plan, draft, and review entirely inside its own boundary without touching anything real. You open doors one at a time, on purpose. The boundary and the five approval points The workspace boundary is the line your data does not cross without your say-so. The five approval points are the only crossings: - Money over your cap. - Public claims under your company name. - Customer data leaving the boundary, including integrations, exports, shares, and training opt-ins. - Production-touching changes, including deploys, infra, billing, and security policy. - Audit-trail edits. Anything that would cross one of these lines stops and waits for you. Everything that stays inside the boundary runs on its own. Connecting a tool When a mission needs a real integration, you grant it explicitly and scope it as tightly as the tool allows. Prefer read-only where read-only is enough. Prefer a single workspace or project over account-wide access. The narrower the grant, the smaller the blast radius if anything ever goes wrong. Keeping access tight - Grant the minimum. Connect only the tools a mission actually needs, and only at the scope it needs. - Use the Security and Infra department. Ask it to inventory every key, set a rotation schedule, and revoke stale or over-scoped credentials. A smaller, named blast radius is the goal. - Review access periodically. The PII flow map shows everywhere customer data lands so you can review who and what can reach it. - Tune your money caps. Lower caps mean more decisions route to you. Higher caps mean more autonomy. Set them where you are comfortable and adjust as trust builds. Revoking access You can disconnect any integration at any time. Because access was granted deliberately and tracked in the evidence trail, removing it is straightforward and the change is recorded. If a key is ever exposed, revoke first and rotate, then let Security and Infra confirm nothing stale remains. A simple monthly habit Once a month, ask Security and Infra for a one-page access review: what is connected, at what scope, last used when, and anything it recommends revoking. Five minutes of reading keeps your surface area honest as your usage grows.

Connecting your tools safely

Integrations are how the agent company reaches your real tools: your CRM, your email, your analytics, your code, whatever a mission needs. AOS treats every connection as a deliberate decision. Nothing is connected until you connect it, and everything you connect is tracked. This article explains how to add integrations safely. The default is deny When your instance is provisioned, integrations are walled off. A fresh instance can plan, draft, and review entirely inside its own boundary without touching anything live. You open each connection on purpose, one at a time. This is the opposite of a tool that asks for broad access on day one. Connecting a tool When a mission needs a real integration, you grant it explicitly. Two rules keep the blast radius small: - Scope as narrowly as the tool allows. Prefer a single workspace, project, or repository over account-wide access. - Prefer read-only where read-only is enough. Many missions only need to read. Do not grant write access the work does not require. The narrower the grant, the less damage possible if anything ever goes wrong, and the easier it is to reason about what the team can touch. Customer data is an approval point Moving real customer data across your boundary, through an integration, an export, a share, or a training opt-in, is one of the five approval points. It waits for your explicit sign-off. So even a connected tool does not get to quietly ship customer data out. That crossing always asks you first. Let Security and Infra manage the keys The Security and Infra department exists partly to keep integrations honest. Ask it to: - Inventory every connected key and its scope. - Set a rotation schedule so credentials do not live forever. - Revoke anything stale or over-scoped. - Map where customer data lands via the PII flow map. A named, monitored set of connections beats a sprawl of forgotten ones. Revoking a connection You can disconnect any integration at any time. Because each was granted deliberately and recorded in the evidence trail, removing it is clean and the change is logged. If a key is ever exposed, revoke first, then rotate, then let Security and Infra confirm nothing stale remains. A safe rollout pattern 1. Start with read-only on the narrowest scope the mission needs. 2. Run the mission and confirm it does what you expected. 3. Grant write access only if a later mission genuinely needs it. 4. Once a month, ask Security and Infra for an access review and revoke what is unused. This keeps your surface area small as your usage grows, so connecting more tools does not quietly turn into a wide-open instance. Common questions Will AOS connect anything automatically? No. Every integration is granted by you. Can I limit a tool to one project? Yes, wherever the tool supports scoped access. Always prefer the narrowest scope. What if I connect the wrong thing? Disconnect it. The action is reversible and recorded. Then rotate the key if it was sensitive.