Solutions
Service accounts, API keys, OAuth applications, and AI agents listed by your platforms. MIA inventories the identities and access each connected source exposes, then shows which links and permissions are available. Assign a responsible person, launch a review, and keep a record of decisions.
The challenge
Non-human identities don't fit into any of these stages. They are created throughout the lifecycle of projects by people who change roles or leave the company, and they retain their permissions indefinitely.
On average, 109 machine identities for every human identity, including 79 AI agent identities.
Source: Palo Alto Networks, 2026 Identity Security Landscape report, survey of 2,930 decision-makers.
They originate in a vendor console, a workflow, or a cloud project, rarely through a formal request process.
OAuth scopes, project roles, delegated connections: every platform expresses permissions in its own way.
The person who created the identity is not necessarily the one responsible for it, and they may no longer even be with the company.
What MIA does
An up-to-date inventory, readable permissions, a person accountable, and a tracked decision. The same method used for your team's accounts, applied to what your platforms expose.
MIA queries your platforms’ administration APIs. Depending on the data they expose, the inventory may include service accounts, API keys, OAuth applications, and AI agents. It is updated with every synchronization.
For each object, MIA displays the owner, permissions, and resources returned by the source. A link reconstructed by MIA is flagged as such; a link that cannot be established remains marked as unresolved.
The owner listed by the provider is not always the right person. In MIA, you designate who is responsible for the object and reassign it when that person changes roles or leaves the company.
New object, modified permission, owner departed: discrepancies are flagged at the next synchronization. Reviews and decisions are recorded in the MIA log, along with their date and author.
The approach
MIA starts with the data your platforms expose through their administration APIs. It shows where each link comes from, including when a link remains unresolved.
The owner is whoever the publisher declares: often the creator, sometimes no one, in which case MIA displays "Not provided by source." The manager is the person you designate in MIA to be responsible for the object and decide its fate. Until one is chosen, the object remains "Unassigned."
The framework
Non-human identities don't require a separate tool. In MIA, they join the framework you already apply to your team's accounts.
Covered sources
MIA connectors cover different scopes depending on the APIs available. The examples below show what to explore with your team; the exact coverage of technical identities, links, and permissions is confirmed source by source during the demo.
Your tenant's agent identities, their owners, and their permissions.
The agents in your environments, their authors, and the connections they use.
OAuth applications authorized by your users and the scopes granted to them.
The agents deployed in your projects and the service accounts they run under.
MIA can inventory members of your OpenAI organization. Visibility into projects, service accounts, and API keys must be confirmed against the available permissions.
MIA inventories organization members through the Claude Admin API. Coverage of workspaces and API keys must be checked separately.
MIA inventories organization members through the Mistral Admin API. Coverage of workspaces and API keys must be checked separately.
MIA can inventory users in your n8n instance. Visibility into workflows and their owners is confirmed during the demo.
MIA can inventory Salesforce users. Coverage of connected applications, integration accounts, and agents must be confirmed for your organization.
The repository of AI systems you maintain in ServiceNow, along with their owners.
What about your other tools? Your employees' accounts remain covered by the MIA catalog: approximately 90 connectors, plus a generic SCIM 2.0 connector.
The demo
No generic datasets: we start with the tools you use and look together at what MIA can inventory within them.
You specify your environment: Microsoft 365, Google Workspace, Google Cloud, OpenAI, Claude, n8n, Salesforce, ServiceNow.
For each one, the visible objects and permissions, the links the API allows you to establish, and those it does not return.
The administrative roles and permissions to grant to MIA, source by source.
Managers, reviews, and logs: how these identities align with the rules you already have in place.
For teams that need to be able to answer, both during audits and on a daily basis: which technical identities have access to what, and who is responsible for them?
🇫🇷 French publisher, hosted by OVHcloud in Strasbourg. MIA only collects metadata: identities, permissions, and dates. It never collects the content of your files, messages, or your interactions with an agent.
A non-human identity is used by a program rather than a person: a service account, API key, OAuth application, or AI agent. It has permissions in your tools like an employee account, but it does not follow an employee’s joiner and leaver lifecycle.
No, and no tool can do so reliably. MIA inventories what your platforms expose through their administration APIs: managed agents, service accounts, API keys, and OAuth applications. A script using a key appears only through that key, if the source returns it.
The owner is the person declared by the vendor, often the object’s creator. The accountable person is the person you designate in MIA to answer for it during reviews. They are distinct: the creator may have changed roles or left the company.
Configured describes what an agent’s definition is intended to do. Granted describes the permission actually assigned to its identity in the platform. Observed describes activity visible in source logs when available. MIA displays these three levels separately.
It depends on the platform. In general, MIA needs a read-only administration role or an administration key created by an organization owner. The prerequisites for each source are detailed in the documentation.
Yes. Each tracked object can be assigned an accountable person and included in your review campaigns, just like employee accounts. Decisions are recorded in the sealed log and support evidence for NIS2 and ISO 27001 audits.
No. MIA connects to your platforms’ administration APIs, without an agent to install or a mandatory SSO. If you already use Microsoft Entra or Google Workspace as your identity provider, MIA works with it without replacing it.
In France, with OVHcloud in Strasbourg. MIA collects only metadata: identifiers, permissions, owners, and dates. It does not read your files, messages, or conversations with your agents.
