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
- Start with read-only on the narrowest scope the mission needs.
- Run the mission and confirm it does what you expected.
- Grant write access only if a later mission genuinely needs it.
- 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.