Security
OA6 is administrative tooling for a tenant that already holds everything worth protecting. This is the detail an administrator should expect before installing it.
Read this first
This guarantee does not depend on how anything else is configured. Every change OA6 makes starts with an administrator choosing one action on one object. Anything that can do harm stops on an approval card that names the operation and the object, and approving one proposal approves that proposal only. Routine actions chosen from the right-click menu, such as a sync or a scan, are sent as soon as you choose them, then show exactly what was sent and offer Undo where there is one.
There is no bulk apply, no queue that drains on a timer, and no preference that turns the approval off. If nobody chooses an action, nothing in your tenant changes.
Boundaries
Every lookup and every action uses the signed-in administrator's own sign-in. Microsoft checks each one against that person's role, so OA6 can never see or do more than their account already can.
An administrator whose role does not let them see or change something cannot see or change it through OA6 either.
Working as you is one control, not the only one. Every change is chosen by a person, and anything that can do harm also waits for them to approve it.
So a change needs both: an account allowed to make it, and someone who chose it.
What OA6 offers against an object also depends on the licenses held by the tenant being administered. A capability your organization has not licensed does not appear, even to an administrator who holds a higher-tier license themselves.
Data flow
This is the question most tools answer vaguely, so here it is directly.
Recognizing the subject and pulling the related objects is a Graph call made as the signed-in administrator. No third party is involved and none of it reaches a model.
What you have open, not your tenant, goes from your browser straight to the model you chose: Claude with your own Anthropic key, or your own model at any OpenAI-compatible endpoint, including one running on your own computer. It never passes through a server of ours, and that provider's terms cover it. Names and IDs are masked first, as described below.
Approving a proposal issues the named call against the named object, and nothing else. It is not executed anywhere else and no part of it reaches a model.
Ask OA6 is off until an administrator turns it on, and even then it never runs on its own. If you never ask a question, nothing ever leaves.
Masking
Before a question leaves your browser, OA6 swaps the details that identify your organization for placeholders. The list of which placeholder stands for what stays in your browser, and OA6 puts the real names back on your screen when the answer arrives. Masking runs before OA6 decides where the request goes, so your own model receives exactly what Claude would.
Users, groups, directory roles, Conditional Access and Intune policies, devices, apps, labels, eDiscovery cases, incidents, and your tenant's name.
In descriptions, alert evidence, file paths, error messages and your own question, OA6 masks:
IP addresses are shortened, IPv4 to a /24 and IPv6 to a /32.
Masking covers identifiers, not meaning. Other text is sent as it appears in your tenant: descriptions, alert titles, policy settings, eDiscovery search queries, job titles, departments and cities, license names and counts, sign-in countries, and device models.
A one-word name inside a sentence, such as a group called Sales, can also pass through as written.
A question asked from the search box with nothing open carries no tenant data at all. It is sent exactly as you typed it, and the panel tells you so before you press send.
Storage and consent
A read answers the question in front of you and is not kept afterwards. OA6 does not replicate your directory, mirror your policies or keep a warm copy of your device estate.
Our service stores metadata about your tenant rather than data from it: which tenant has a subscription and which features it is entitled to. Every record is keyed on the tenant identifier Microsoft signs into the token, so one customer's records cannot be reached from another customer's session.
OA6 records each action you approve, in your browser: what was proposed, who approved it and what the tenant answered, so the history of what OA6 did is in one place. Each administrator can also send that record to your own SIEM, as described below.
OA6 lists the access it needs in full on the Microsoft consent screen before anything is granted. Capabilities that need materially more access are requested separately, when you first use them, rather than bundled into the first screen. You can revoke consent in Entra ID at any time without involving us, and OA6 stops reaching your tenant immediately.
The permission model is the consent screen. Read the exact access at the moment it is requested rather than a summary of it on a marketing page.
Everything we operate runs on Microsoft Azure. There is no separate cloud account, no third-party database and no payment processor holding your card details. Our service holds no account keys or connection strings: it authenticates to its own resources with managed identities, so there is no credential in a configuration file to leak.
Log portability
By default OA6 receives the activity log. If you would rather house it yourself, each admin can send theirs to your own SIEM instead.
By default, OA6 receives your activity log and uses it to build automations and track telemetry.
In the extension's options, choose your own SIEM and enter its endpoint URL and API key. It works with Splunk (HTTP Event Collector, which also covers Cribl), Elastic, Datadog, and any HTTPS endpoint that accepts a JSON POST with a bearer key.
Activity goes straight from your browser to your SIEM. Your SIEM key stays in your browser and OA6 never sees it. It is kept in memory only, so you paste it again after the browser restarts, and activity waits on the device until you do.
Each admin sets this in their own browser and it applies only to them, so it runs as that admin like everything else in OA6.
They also pick which tenants go to their SIEM. OA6 receives no activity for those tenants, and activity in any other tenant still comes to OA6.
Status Sending your activity log to your own SIEM is in the current release. OA6 receiving it by default is not switched on yet.
Automations · Build in progress
An automation is a response you ran once, saved as a rule and tested before it is armed. When the same thing is detected again, the rule builds the whole response on one card. The trigger is automatic. Whether the act is too is your choice at arming: run unattended, or wait for approval. A rule’s first life waits for approval, so anything that can do harm runs only when an administrator approves it on the card, and it runs as that administrator. Promoting a rule to run unattended takes a second administrator. Each time a rule fires, three checks have to pass. They are read fresh every time, never copied onto the rule.
The access your organization granted OA6.
The Microsoft permissions of the person who armed the rule, as they stand that day.
Your OA6 policy, which decides which actions always wait for a person.
All three, every time. A rule stops when the person who armed it leaves, and every firing is recorded with the rule and who armed it.
Status Build in progress. Automations is being built and is not available yet. This is its current design, and it may change before it ships.
Ask us about anything on this page before you install.