AI Output and Your Responsibility
InfraScout runs infrastructure and cloud security assessments through a language model. That is what makes it fast, and it is also what makes it fallible in a way a fixed script is not. This page explains what the model is actually deciding, what that means for the findings you read, and where responsibility sits when somebody acts on them.
This is operational guidance. The binding version is § 4 of the Terms of Use, which you accept when you use InfraScout — this page says the same thing at more length, not anything different.
What the Model Decides
The model is not doing the collecting. Agents run the commands on your hosts, Microsoft Graph returns your tenant configuration, and the tool layer hands back structured results. That part is deterministic: the same question against an unchanged environment returns the same data.
What the model supplies is judgment — which host to pivot to after a suspicious service account turns up, whether an expiring certificate is routine or load-bearing, whether a finding is critical or merely worth noting, how to word it so the person reading it next week can act on it.
That is where the failure modes live. A model can misread a configuration it retrieved perfectly, rate a risk your environment already compensates for as severe, or simply not think to look somewhere. In the words of the Terms, AI output may be inaccurate, incomplete, or misleading, and you must independently verify it before relying on it.
Findings Are a Draft Until Someone Accepts Them
An assessment does not publish its conclusions. It is submitted for review — the session moves to a pending state, and only a person moves it to completed. Each finding carries a status of its own, and records who created it and who last changed it, including when a scheduled workflow rather than a person wrote it.
Treat that review as the substance of the process rather than a formality at the end of it. A finding cites the evidence it came from: the command output, the tenant setting, the sign-in record. Reading the evidence is what separates a finding that holds up from one that reads well, and it is the step nothing else in the system can do for you.
Never let a finding be the only thing behind a change
This matters most exactly where the stakes are highest — actions affecting production systems, security configuration, or compliance posture. An AI-generated finding is a reason to look, not authorization to act.
Actions Against Your Infrastructure Are Yours
InfraScout can change things, not only read them. Reading is the default: every tool that modifies a host sits behind the operator tier, which is assigned in your own Entra ID, and tools whose effects may be irreversible are marked as destructive — a shell session can run rm as easily as ls.
When someone with that tier approves an action the model proposed, it is your change, on your system, made by your operator. InfraScout is not responsible for decisions or actions you take on the basis of AI output. The practical consequence is that deciding who holds the operator tier is the most load-bearing access decision you will make here, and it deserves more scrutiny than it usually gets.
Your Keys, Your Vendor Terms
Model connections run on API keys you supply, under your own agreement with that vendor. Usage is billed to you, the vendor's terms and acceptable-use policy apply to you directly, and keeping those keys confidential is your responsibility.
That also makes it a data-handling decision. An assessment sends real material to the model you pointed it at — command output from your hosts, tenant configuration, identity and device data. Whatever your agreement with that vendor says about retention, regional processing, and whether your traffic may be used for training is what governs, and InfraScout cannot enforce different terms on your behalf.
What Governs
Three sections of the Terms of Use carry the formal position, in English and German: § 4 on bring-your-own AI keys and AI outputs, § 8 on the disclaimer of warranties, and § 9 on the limitation of liability. Nothing on this site overrides them, and this page is not legal advice.
If you need the data-residency or review position in writing for a specific engagement, get in touch rather than citing a documentation page.
Related
The pages below are part of the product documentation and ask you to sign in with a Microsoft work or school account — what to expect when you sign in.
- Choosing a Model — which model tier to run on, and what each one is good for
- Tool Annotations and Role Scoping — how the read-only boundary and the operator tier are enforced
- Insights — the status workflow a finding moves through
- Running Assessments — sessions, executions, and submitting for review