How InfraScout Secures Your Infrastructure

July 15, 2026 · InfraScout Team

InfraScout runs commands against your infrastructure and holds credentials for your Microsoft Cloud tenants. A platform that does that has to earn trust at every layer, not just claim it. This post walks the trust model end to end — how agents reach the server, how people sign in, what each person is allowed to do, what they can see, and what gets recorded — and points you to the new Security Architecture page for the full detail behind each layer.

Agents connect out — nothing dials in

The agent on each of your hosts opens the connection to the server; the server never reaches into your network. That direction matters: there is no inbound port to expose, and no listening service on your hosts for an attacker to find. The connection is protected end to end by mutually authenticated TLS (mTLS), so both sides prove who they are before any work crosses the wire — the agent verifies the server, and the server verifies the agent.

That mutual proof rests on how an agent is enrolled. Each agent joins with a single-use enrollment token and is issued its own signed certificate, which becomes the identity it presents on every later connection. The token works once and then it is spent, so a leaked token cannot be replayed to stand up a second agent. The agent renews its own certificate well ahead of expiry and reconnects, without anyone touching the host.

The pieces that install and run on your machines are signed, so you can verify their origin before you trust them. The Windows agent binaries carry a digital signature, and the onboarding script you run inside your own tenant is signed as well. We covered both in detail when they shipped — see signed Windows agent binaries and the signed onboarding script.

People sign in with Entra ID

Everyone who uses the portal signs in with Microsoft Entra ID. InfraScout keeps no separate password store of its own, so there is no second set of credentials to manage, leak, or attack. Your existing conditional access, multi-factor policies, and group membership all apply exactly as they do to the rest of your Microsoft estate, and a user who leaves your tenant loses access the same way they lose access to everything else.

Access is scoped to the role

Signing in tells InfraScout who you are; your role decides what you can do. Standard users are confined to read-only tools and cannot invoke anything that would change your environment. This is enforced at the platform, not merely hidden in the interface — the same limit holds when a user connects a direct MCP client such as Claude, so there is no side door around it. We described how this works in role-scoped tool access.

The read-only guarantee is also checked before an assessment runs, not assumed. When an assessment is meant to observe rather than change, InfraScout validates that it stays within read-only bounds ahead of execution, so a run that oversteps is stopped rather than caught after the fact. See validated read-only execution for the detail.

Visibility is closed by default

Being allowed to run a tool is separate from being able to see a given host, group, or connection. Resource visibility in InfraScout is closed by default: a resource with no visibility groups assigned is visible to admins only, never to the whole tenant by accident. Every widening of access is a deliberate act, which means a newly registered agent is not exposed to everyone the moment it connects. We walked through the model and what to do after the change in visibility closed by default.

Everything is auditable

A platform that can run commands against your infrastructure has to be able to show what ran, when, and on whose behalf. InfraScout records sessions, executions, and chats, so the history of what happened is there to review rather than reconstructed from memory. The insights surfaced in the portal trace back to the executions that produced them, so a finding is never a claim you have to take on faith — you can follow it to the command behind it. This is the property that turns "we ran an assessment" into evidence you can stand on.

Read the full picture

Each layer above holds on its own, and together they form a trust model where reaching your infrastructure means clearing authenticated transport, Entra sign-in, role scope, and visibility in turn — with a durable record of everything that ran.

TIP

The new Security Architecture page covers every layer in this post in depth, in one place — keep it handy when you are answering security questions about InfraScout.

Questions about any of this? Reach us at info@infrascout.cloud.