1Security + Microsoft Agent 365
Agent 365 manages the agents you register. 1Security secures every agent's reach - shadow AI included.
Microsoft Agent 365 is the control plane: a registry, an Entra identity and lifecycle rules for the agents you register. 1Security is the measurement layer underneath - every agent, registered or shadow: the exact files, sites, users and mailboxes it can reach, its activity, anomalies and the people who run it, on one graph with everything else in your tenant. Read-only consent, first inventory the same day, starting on the licenses you already own - and growing with every license you add. Turn write access on when you are ready, and the same screens grant, revoke and block - every action staged behind a review window.
- Copilot Studio
- Azure AI Foundry
- Entra Agent ID
- Third-party agents
- all on one graph
What Agent 365 does
A registry, an identity and a lifecycle for every agent.
Microsoft built the control plane agents were missing. If your tenant runs Copilot Studio and Azure AI Foundry, three of its decisions are worth building on.
Agents become identities
Entra Agent ID gives every registered agent a real identity: an owner, credentials, conditional access. An agent stops being an anonymous automation and becomes something you can hold to the same standard as an account.
One registry, controlled onboarding
A single inventory for agents from Microsoft platforms, ecosystem partners and your own teams, with policy templates at onboarding and lifecycle rules that expire the stale and flag the ownerless.
The admin tools you already run
Agents are managed through the Microsoft 365 admin center, Entra, Defender and Purview - the same consoles your team already uses for people, so governance actions have a familiar home.
The next question
The registry says what exists. Reviews ask what each entry can touch.
A registry answers the first question - which agents do we have. The moment it does, every review asks the second: what can this one actually reach? Scope names don't answer it. Sites.Read.All is one line on a consent screen; in a 10,000-person tenant it is millions of files, and the difference between an agent that answers invoice questions and one that can read the board folder is invisible at that level.
Agents also inherit. A Copilot Studio agent wired to a finance site inherits every permission that site collected over the years: the "Everyone except external users" grant from an old deadline, the guest who never left, the anyone link on a spreadsheet. The agent is a week old; its reach is as old as your tenant.
And agents are only half the picture. Every agent has an owner, users and a blueprint - people whose own access and behaviour decide what the agent ends up doing. An agent that behaves normally under a user who suddenly doesn't is a human story wearing an agent's identity.
What 1Security adds
Reach, behaviour and owners - resolved, not declared.
1Security connects read-only to the same tenant and resolves every agent the way it resolves every human identity: what it can open, what it actually did, and who is behind it.
- 01
Every ecosystem, one inventory
Copilot Studio agents, declarative Copilot agents, Azure AI Foundry, Entra Agent ID and third-party SaaS agents on one list - owner, origin, creation date, last activity. A blueprint is reviewed once instead of chasing fifty clones through the tenant.
- 02
Reach resolved to content
Not scope names: the exact files, sites, users and mailboxes each agent can touch, resolved from knowledge sources and permissions through the same graph that maps your humans - and ranked by the sensitive data inside: payment cards, health records, credentials.
- 03
Permissions you can read
Every atomic permission with its source - direct, inherited or declared - plus Microsoft's own blocked-for-agents flag. An access review for an agent takes minutes, and the answer holds up in front of an auditor.
- 04
A baseline per agent - and per user
Every agent is watched against its own 30 days of history, and so is every person who runs one. "This agent read 4× its usual files today" becomes an episode above your alert line within minutes of the audit event.
Context quality
What an agent can reach is what it will say.
An agent's answers are only as safe as its grounding. 1Security shows the grounding as content, not configuration: which sites and folders the knowledge sources resolve to, which of those files carry sensitive information types, and which users could get that content back in an answer.
That turns two recurring meetings into lookups. Before an agent ships: what would it read, and should it. After it ships: did its reach grow last week because someone edited a knowledge source - or because a site permission changed underneath it, with nobody touching the agent at all.
Anomaly alerting
Watched like an employee. Flagged like an incident.
Every agent gets an anomaly baseline of its own: today's activity measured against the median of its previous 30 days, scored against the agent's normal variability. The same machinery watches the agent's users - so a person suddenly driving an agent into folders they never opened surfaces too, as one episode, not five hundred log lines.
There are no rules to write and nothing to tune. Baselines build silently from your first two weeks of history and then go live; detection fires within minutes of a new audit event, and the alert line is one dial - move it, and past episodes reclassify against your real history, not a vendor's defaults.
Access control
Seeing the reach is half of it. Closing it is the other half.
Visibility ends in a finding. This ends in a change: grant, revoke or block, from the same row that measured the reach - and only once you turn write access on.
- 01
Grant what the agent actually needs
Add the site membership, the group or the licence an agent - or the person it runs as - legitimately needs, from the row where you saw the gap. The engine that takes access away is the one that hands it out, so "the finance bot gets the finance site and nothing else" is one action instead of a ticket and a week.
- 02
Revoke the grant behind the reach
Agents run on permissions, not on good intentions. Revoke the direct grant, the nested membership or the anyone-link that produced the reach, and it is gone - for the agent and for everyone else who was riding the same path. Every removal names the exact grant it removes, so the change is reviewable after the fact.
- 03
Block the path to the data
Turn Copilot off for a site, close its external sharing, expire its links, or disable the account an agent runs under. Agent 365 retires the agent identity; 1Security closes the data path it was using - the site, the link, the membership, the account - which is the half that survives the next agent built on the same permissions.
- 04
Nothing fires unreviewed
Every action is staged as a proposal inside a review window - 72 hours by default. Approve it, reject it, snooze the resource, or route it to the owner of the resource, who answers in their own restricted portal. Silence applies it. Everything that ran sits in one audit trail with who decided, when, and what it changed.
- Read-only by default
- Write access is a separate consent
- Review window per policy
- Owner review
- Full audit trail
Licensing
Starts on the licenses you already own. Grows with the licenses you add.
A large share of the agent estate is visible on the Microsoft licenses you already own. Entra Agent ID and Azure AI Foundry agents appear in the inventory from day one - they arrive through the same integration that maps your enterprise apps, and third-party agents surface at that same layer.
Copilot Studio and declarative Copilot agents sit under Microsoft's Agent 365 licensing, and 1Security follows that model: license what you decide to license, and 1Security reads those agents through the access Microsoft provides. As your Microsoft licensing grows, coverage grows with it - add Agent 365 and those agents light up in the same inventory, with nothing to reconfigure.
And nothing drops to zero: declarative Copilot agents without Agent 365 coverage still appear as enterprise apps with their app-level permissions. You lose detail, never the inventory.
- Day 1Entra Agent ID, Azure AI Foundry and app-layer agents, on the licenses you own
- Growswith your Microsoft licensing - add Agent 365 and those agents join the same inventory
- Same dayfrom read-only consent to the first full agent inventory
One source of truth
Agents join the graph everyone else is already on.
Agentic visibility isn't another console to check - it's a new identity type on the graph you already needed. The inventory that lists your agents is the same graph that maps your people, guests, OAuth apps, devices and data. "Which agents can reach the M&A folder" and "which people can" are the same query, answered from the same source.
That's what makes the numbers defensible. When the board asks how many identities can reach a sensitive site, the answer includes the agents. When the auditor asks what changed since last quarter, three years of activity history answer - for agents and humans alike.
Enterprise ready
Built for the 10,000-seat tenant, not the demo tenant.
Two things large organisations check first: what deployment touches, and what it costs to try.
Deployed your way
SaaS by default, or on your own cloud and your own servers when data residency or procurement requires it - the same product inside your own boundary.
Read-only until you opt in
One consent screen, no software to install, nothing written to the tenant. Remediation exists, but it is opt-in and staged behind a review window - visibility never requires write access.
Your existing agents, as they run
Nothing to re-register, migrate or re-platform: 1Security discovers Copilot Studio, Foundry, Entra and third-party agents from Microsoft's own surfaces, exactly as they already exist.
- Read-only consent
- Runs on your licenses
- Same-day first inventory
- Self-hosted option
- 3 years of history
The evaluation
Evaluating Agent 365? Start with the number it would manage.
An organisation with Copilot Studio and Azure AI Foundry in production is past the question of whether agents are coming. They're already there - built by business teams and platform teams at different speeds, in different portals. The evaluation questions are concrete: how many agents exist today, what can each one reach, and which of them justify a managed rollout.
1Security answers that before the evaluation meeting, not after the rollout. Connect in the morning; by the end of the day you have every agent from every ecosystem, its owner, its reach into sensitive content and its last activity. The stale experiments get retired instead of licensed. The agents that matter run with their adoption and their reach under your control.
Every new agent lands on the same 1Security graph as a data consumer, next to the people who use it - so you decide what data is reachable, whoever is reaching for it: a person or an AI.
Count your agents before you license them.
Connect read-only in the morning. By the end of the day: every agent from every ecosystem, what each one can reach, and who runs it - on one graph with the rest of your tenant.
Or keep estimating the agent count from memory.