Security Architecture
InfraScout is Infrastructure as Chat: you assess your IT estate by talking to an AI client, and InfraScout does the work through agents on your hosts and read-only connections to your Microsoft Cloud tenant. Because that puts InfraScout close to sensitive systems, its security model is worth understanding before you rely on it. This page is a tour of that model from your side of the boundary — the parts you can see, verify, and control.
The trust model rests on four ideas that reinforce each other: every agent is authenticated, every person is authenticated, every action is scoped to who is asking, and everything that happens is written down. One principle sits underneath all of them — InfraScout never initiates a connection into your network. Agents dial out to InfraScout over an encrypted channel; there is no inbound port for InfraScout to reach your hosts, and no path for it to knock on your firewall from the outside.
Agent Trust
An agent is a lightweight binary you install on a host you own. It connects to InfraScout over mutually authenticated TLS (mTLS), which means both sides prove their identity to each other before any command flows — the agent verifies it is talking to InfraScout, and InfraScout verifies the agent is one you enrolled. Neither end trusts the other on assertion alone.
That identity is established once, through enrollment. You generate a one-time enrollment token in the portal and hand it to the agent during setup. InfraScout uses the token to confirm the agent's identity and issue it a signed certificate; the token cannot be reused afterward. From then on the agent authenticates with its certificate, not the token, and certificates are renewed automatically well before they expire — the agent rotates onto a new certificate and reconnects without any action from you. When you revoke or delete an agent, the certificate it is actually connecting with is the one that stops working.
The software itself is verifiable too. The Windows agent binaries are digitally signed with a publicly trusted, Microsoft-issued certificate, so Windows shows you the publisher rather than an unknown-publisher warning. The onboarding script you run in your own tenant carries the same signature, giving you one consistent, checkable identity from the first script you run to the agents you install afterward.
Verify it yourself
You do not have to take the publisher on faith. Both the agent and the onboarding script report a valid signature and a named publisher through standard Windows tools — see Windows agent binary signing and onboarding script signing.
Human Authentication
People sign in to the InfraScout portal and API through Microsoft Entra ID. There is no separate InfraScout password store to manage, no second set of credentials to rotate, and nothing for InfraScout to leak — your existing identity provider is the single source of truth. Conditional Access, multi-factor requirements, and any other sign-in policies you already enforce in Entra apply to InfraScout automatically.
That cuts both ways: InfraScout is exactly as well defended as the policy in front of it, and the default for most tenants is weaker than a platform with this reach deserves. Hardening Sign-In with Conditional Access sets out a recommended baseline built around phishing-resistant authentication, managed devices, and bounded sessions — including which InfraScout paths a policy can reach and which it cannot.
Access is deliberate rather than automatic. During tenant onboarding, an Entra administrator enables the InfraScout application and turns on the switch that requires an explicit role assignment to sign in. Without it, every user in your tenant would become an InfraScout user the moment they authenticated; with it, only the people you assign can get in. That switch is the boundary that keeps InfraScout scoped to the users you choose.
Authorization — Roles and Tool Access
Signing in gets you through the door; your role decides what you can do once inside. InfraScout maps its roles to Entra app role assignments, so the same identity that authenticates you also determines your tier. Standard user-tier roles are for read-only stakeholders who view the dashboard, agents, and findings. Operator-tier roles — your operators and admins — add running sessions, executing playbooks, and updating findings, with admins layering on user management and connection setup on top.
Those tiers are more than a UI convenience: they are enforced at the tool boundary. A user-tier caller is confined to read-only MCP tools, and that confinement is applied by InfraScout itself before any tool runs — not by instructing the AI to behave. Crucially, it holds on every path a caller can take, including a raw MCP client pointed straight at the server, not just the chat experience in the portal. The tier is decided from your identity server-side, so a caller cannot ask its way into a higher one, and the boundary is fail-closed: when in doubt, InfraScout treats a request as read-only rather than letting it through.
Read-only assessment work is validated on its own merits, too. When an assessment inspects a Windows host with PowerShell, the read-only execution path checks each script against a command policy before dispatch. A script that reads is sent; one that appears to change the host — stopping a service, editing the registry, writing a file — is denied and never leaves the server, so it has no effect on the machine it targeted. Admins tune that policy with allow and deny lists on top of a safe-by-default floor.
Least privilege by default
A standard user — or an AI client acting on their behalf — can inventory hosts, pull configuration, and review findings, while the tools that would change a system stay out of reach. See role-scoped tool access and read-only PowerShell for the details.
Visibility — Closed by Default
Authorization decides what a role can do; visibility decides which resources it can even see. Agents, agent groups, tool groups, playbooks, and AI provider connections are each scoped to one or more Entra groups, and only members of those groups can see them — while admins always see everything.
The default is the safe one. A resource with no groups assigned is visible to admins only, so a newly registered agent is never exposed to your whole tenant before anyone has decided who should see it. Widening access is always a deliberate act: scope a resource to specific Entra groups, or mark it Everyone when it genuinely should be tenant-wide. Agents inherit visibility from the groups they belong to, so scoping a group covers its members in one pass — and where a sensitive host sits inside an otherwise broadly visible group, a per-agent block inheritance switch keeps it hidden regardless.
For the full model and the administration surface, see resource visibility, closed by default and the Groups admin page.
Auditability
Every assessment leaves a complete, reviewable record. A session bounds each assessment run; within it, every execution captures the command, its output, its timing, and whether it succeeded. Blocked executions are recorded alongside the ones that ran, marked distinctly, so a script the command policy turned away is just as visible as one that reached a host. Chat conversations are persisted as well — including a turn interrupted by a closed browser tab, so nothing that ran against your infrastructure can slip out of the transcript.
The record is also connected. Every insight InfraScout saves links back to the executions that support it, so a finding is never an assertion you have to take on trust — you can follow it to the raw evidence that produced it. Because access is authenticated and role-scoped, each action is attributable to the person who authorized it.
You review all of this in the administration audit views: the executions trail for what ran on your hosts, the chat trail for conversations, and the MCP session trail for tool activity.
Data Handling
InfraScout assesses your environment where it already lives. Agents run on hosts you own and manage, and they execute assessment commands locally, returning only the results — the work happens inside your estate, not in a copy of it somewhere else. For Microsoft Cloud, InfraScout connects to your Entra tenant with read-only, admin-consented permissions and reads through Microsoft Graph on demand; it never writes to your directory or your cloud services, and there is no bulk export of your tenant.
The AI client is the one component outside your infrastructure, and you choose it. InfraScout supports Claude today, with additional providers configurable by an admin, and where a provider processes conversation data is a property of the provider and region you select. You control which provider your users can pick through the AI provider connections admin surface, so the data-handling posture of an assessment follows a choice you make deliberately rather than a default you inherit.
Credentials belong to a separate class of data and are handled as one. API keys, MCP server headers and environment variables, LDAP bind passwords, and OAuth tokens are stored encrypted and never displayed back to you as values — the admin surfaces show a masked hint that identifies which secret you are looking at without revealing it. Secrets pushed to an agent travel only over its authenticated channel and stay in the agent's memory; the agent writes none of them to disk, which is why a host that reboots is re-provisioned from the server rather than restored from a local copy.
The content your assessments produce can additionally be encrypted at rest with keys held per tenant — conversations, memory, delegated run records, execution output, and insight evidence. This is enabled per tenant rather than assumed; talk to us if your compliance posture requires it.
Limits on What a Read-Only Caller Can Reach
Role-scoped access is only as strong as the classification behind it, and two boundaries in this batch tightened as a result.
Reading files on a host is a genuine assessment need, so InfraScout offers a log reader rather than making people shell out for it — and because it cannot change anything, it is available to read-only callers. But the agent runs with full system privileges, which means an unrestricted file reader would have been a credential-disclosure tool wearing a log reader's label. A hard denylist now refuses the well-known credential locations outright, whatever the caller's role: the Windows account databases and their shadow copies, /etc/shadow, SSH and TLS private keys, cloud token caches, and the agent's own certificate material. Matching is done on the resolved path, so a share path, a shadow copy, a traversal, or a symlink pointing at a denied file is refused the same way.
Third-party tools registered through an MCP server are classified fail-closed. A tool reaches a read-only caller only where it is positively marked read-only — either by the server's own declaration or by a tenant admin's override. A tool that declares nothing is treated as though it writes, because trusting silence would mean assuming a safety property nobody asserted.
Learn More
Key Concepts
Definitions for agents, sessions, executions, insights, and visibility.