Planned security requirements
Keep infrastructure work within clear boundaries
The planned product must preserve clear boundaries from discovery and assessment through scenarios, approval, execution and verification. Organization and deployment scope, least privilege and inspectable evidence are requirements to validate, not claims of implemented controls or certification.
Customer and organization boundaries
Each request must resolve to an authorized organization and deployment scope. For MSPs, customer access remains separate; internal IT sees its own authorized environments. Results, topology, scenario estimates, logs, caches and exports must preserve the same boundaries, even across mixed infrastructure.
Limited access from the start
A read-only first implementation and collector agents are recommended. Connections must request only the access needed for each qualified operation; monitoring collection and retention need explicit limits. Credentials belong in protected connection flows, not chat or reports. Observation access must never silently become permission to change workloads.
Connections must be independently revocable. Planned web, iOS and Android clients must share backend-enforced authentication, tenant permissions, approvals and audit. Provider and agent credentials must not be embedded in mobile clients. Self-hosted, managed-hosted and optional external AI-client data paths and operating responsibilities must be documented before evaluation.
Software-enforced checks
AI can explain evidence and prepare supported queries or plans. Authentication, authorization, input and target validation, cost arithmetic, policy gates and execution state must be enforced by software. Provider metadata and researched content cannot grant permissions or bypass controls. The specialized assistant needs sandboxed and adversarial evaluation, including prompt-injection defenses; model adaptation is not a substitute for these controls.
Bind approval to the action, then verify its outcome
Later manual operations need an exact human-approved plan and resource scope, required permissions, fresh-state checks and action-specific recovery prerequisites. Material drift or changed risk invalidates approval. Patch and update plans also need approved maintenance windows, staged rollout, reboot or availability-impact review and post-update validation. Verify every outcome; stop or escalate uncertainty. Firewall changes require stricter impact and lockout/recovery review. Recovery may need tested backups, snapshots or restoration procedures: inventory is not a backup, and rollback is not universal.
Bound optional repair policies and keep an inspectable record
Optional self-healing would use separately human-approved policies and allowlisted runbooks for selected resources or domains. A default-off design is recommended, with least privilege, fresh validation, action-specific recovery prerequisites, bounded retries/cooldowns, a global kill switch and escalation. High-risk, destructive or security-sensitive changes remain separately gated. Record actor, scope, evidence, the approved plan or authorized policy/runbook, a concrete action record and verified before-and-after results. Append-only, retention-protected records and integrity checks need validation; exclude secrets and unnecessary personal data.
Questions before an evaluation
Confirm hosting location, data flows, subprocessors, retention, incident handling and access responsibilities for the actual deployment. Review agent permissions and research sources. Self-hosting does not itself mean offline operation or no data sent to an AI provider. This page establishes no compliance certification, data residency guarantee, SLA or zero-retention commitment.