Every hard question deserves a direct answer.
Trust is earned under inspection.
Infraveil does not ask serious customers to accept vague assurances. It answers the uncomfortable questions before procurement, security review, engineering leadership, legal, finance, and operators have to drag those answers out of it. This page is the inspection surface: SOC 2 posture, signing keys, tenant boundaries, audit trails, lock-in, safe degradation, self-hosting, failure modes, data ownership, incident response, support expectations, and the exact difference between useful dependence and coercive lock-in.
The correct answer is not confidence. The correct answer is evidence.
Enterprise trust is not created by saying enterprise. It is created by repeatable controls, auditable behavior, safe failure design, clear ownership boundaries, and a procurement path that does not depend on charm. Because Infraveil centralizes backend operations, Infraveil makes itself more inspectable than the fragmented stack it replaces. The bar is not lower because the product is easier to use. The bar is higher because the platform becomes operationally important.
The right position is simple: ask the hard questions. Ask them early. Ask them in writing. Ask what runs locally, what data leaves the machine, who can act, what is signed, what is logged, what can be exported, what happens when the control plane is unreachable, and what the customer can verify without trusting a sales page. Infraveil treats that level of detail as the standard, not an inconvenience.
Infraveil's strategic edge is that many of these questions are not weaknesses. They are exactly where the architecture becomes visible. Source-visible launcher and agent behavior, local runtime state, cached payload continuity, bounded restart behavior, explicit operator actions, and service evidence give the platform a concrete way to answer trust questions instead of turning them into slogans.
Are you SOC 2 certified?
Infraveil does not claim a completed SOC 2 certification on this page. Infraveil's position is direct: certification is a formal audit outcome, not a marketing adjective. The platform is being written around the controls a SOC 2 process evaluates: access control, change discipline, auditability, incident handling, data handling, availability thinking, and security monitoring. If certification status changes, the claim belongs in formal trust documentation, not vague copy.
What evidence does Infraveil produce for review?
Infraveil's operating model naturally creates evidence: launcher enrollment, agent heartbeat, service state, deployment actions, operator actions, billing-aware access, incident state, status changes, and recovery activity. The product direction is to make those records attributable and reviewable so security reviewers can see who acted, what changed, which target was affected, and what the runtime reported afterward.
How are tenants separated?
Infraveil treats the workspace as the authority boundary. Customer servers, launchers, agents, APIs, deployment state, operator actions, billing state, support context, and audit events resolve through workspace-scoped ownership. The security position is not UI filtering. Sensitive actions belong behind server-side authorization that verifies tenant, role, target, and action scope.
How are commands and payloads trusted?
Infraveil's control model is built around scoped, verifiable authority. Launcher and agent behavior exists because commands and payloads cannot be trusted merely because a dashboard displayed them. The platform uses signed or scoped command paths, payload verification, hashes/signatures where appropriate, and target-aware authorization so runtime actions map back to an approved workspace and service.
Can Infraveil deploy code without your approval?
Not once you turn on release approval. You register an Ed25519 public key; the agent then refuses any payload that is not signed by the matching private key — which lives only on your infrastructure and which Infraveil never holds. You approve releases with a self-hosted approver (review each, allow-list, or auto), so even a fully compromised control plane cannot push code your key did not sign. The veto, and the only key that satisfies it, are yours.
Who can restart, kill, deploy, or modify services?
Infraveil separates observation from operation. Viewing telemetry is not the same as restarting a service. Restarting one API is not the same as clearing a host workspace. Deleting a server is not the same as reading logs. The platform's position is that consequential actions require explicit permissions, backend enforcement, and auditability.
Can the customer reconstruct what happened?
Yes: that is core to the product thesis. Infraveil treats operational history as part of the platform, not an afterthought. The audit trail connects actor, action, target, timestamp, result, and runtime evidence. A serious operator gets the chain: who initiated an action, whether the launcher or agent accepted it, and what changed afterward.
Is this vendor lock-in?
Infraveil's position is that useful dependence is not the same as coercive lock-in. Customers may rely on Infraveil because one coherent operating layer is better than scattered tools. That is product value. Coercive lock-in is hidden formats, blocked exports, opaque runtime behavior, or artificial exit pain. Infraveil competes on coherence, not captivity.
How clean is the escape hatch?
Infraveil's exit standard is operational clarity. A leaving customer gets operational clarity: what was deployed, where services ran, what runtime components exist, what credentials to rotate, what records to export, and what host enrollment to revoke. Infraveil treats offboarding as boring, documented, and evidence-preserving.
Can customers self-host parts of the control plane?
Infraveil does not pretend every enterprise deployment model exists automatically. The current architecture already keeps meaningful runtime authority on customer infrastructure through launcher and agent behavior. That gives the company a credible path toward dedicated, private, or partially self-hosted control-plane models where enterprise requirements justify them.
What happens if Infraveil is unreachable?
The runtime is designed around continuity, not helplessness. Launcher and agent behavior preserves local state, known-good payload history, restart boundaries, and runtime supervision so customer services do not instantly become useless when the control plane is temporarily unavailable. Infraveil treats control-plane outage as a condition to degrade through, not a reason to panic.
Who owns customer data and operational evidence?
The customer owns the business context, service behavior, logs generated by their systems, and operational history tied to their workspace. Infraveil processes operational data to provide the platform: visibility, coordination, security, billing, support, audit, and recovery. The company position is explicit data purpose, not vague data capture.
How are secrets handled?
Infraveil treats secrets as privileged material, not regular dashboard content. Secrets are not supposed to become casual log text, assistant context, screenshots, or support artifacts. The platform direction is scoped usage, encryption, redaction, rotation support, and customer-side secret discipline where provider-native or environment-level systems are the better home.
Can support impersonate customers?
Infraveil treats support access as privileged infrastructure. Support cannot be an invisible operator path. Any assisted access model belongs behind consent, scope limits, logging, time limits, and customer visibility. The company standard is help without hidden authority.
Does the assistant create security risk?
The assistant is an interface, not the authority model. Infraveil does not treat chat as permission to bypass controls. The assistant can explain, summarize, inspect allowed context, and propose actions. Consequential operations still belong behind scoped tools, permissions, confirmation, and audit records.
What about HIPAA, PCI, GDPR, and regulated data?
Infraveil does not blanket-claim regulated workload readiness from a marketing page. Regulated use depends on contracts, data flows, subprocessors, retention, breach procedures, deployment model, and customer obligations. The company position is precision: support what is actually supported, restrict what is not, and document the boundary.
Why does procurement approve a young platform?
Procurement approves risk-adjusted value, not age alone. Infraveil answers with bounded adoption, live demo access, source-visible runtime components, documented architecture, operational evidence, support expectations, billing clarity, and a staged path from low-risk workloads to broader operating trust.
Does source-visible runtime code make copying easier?
Infraveil accepts that isolated ideas can be studied. The company is not built around one hidden file. The defensible layer is the cohesive operating model: launcher, agent, server, dashboard, incidents, catalog, status, billing-aware access, support, documentation, recovery, and speed of execution working together.
What counts as an incident?
Infraveil does not classify every offline launcher or agent as an incident. Offline is a state. Incident is impact plus reason, threshold, customer expectation, duration, or service consequence. The platform distinguishes offline, degraded, maintenance, misconfigured, unreachable, and impacted because accuracy matters more than drama.
What if the platform makes a bad decision?
Infraveil reduces automation risk with bounded actions: restart budgets, approval gates, policy scopes, rollback paths, health checks, and audit trails. The company does not define production-grade automation as constant action. It defines it as constrained action with evidence and a safe stop point.
Is the pricing credible for this much platform?
Yes, because the value is architectural consolidation. Infraveil replaces a chunk of manual glue and multi-tool coordination with one operating surface. The moat is not artificial inflation. The moat is engineering complexity made operationally simpler for teams without enterprise budgets.
Do you support SSO, SAML, SCIM, and enterprise identity?
Infraveil treats enterprise identity as a real requirement, not a nice label. The platform direction is secure account access first, then organization-managed identity with SSO/SAML, provisioning, role mapping, and session controls where enterprise customers require it. The current claim is not fake completeness; it is a clear identity roadmap tied to workspace authority.
How is MFA handled for consequential actions?
Infraveil treats MFA as action protection, not only login protection. High-impact actions such as deleting servers, clearing local workspaces, rotating authority, changing production policy, or approving destructive remediation belong behind step-up verification and explicit operator intent.
How granular is role-based access control?
Infraveil models permissions around real operational roles: view, operate, deploy, secure, bill, support, and administer. A finance user does not need runtime control. A support user does not need secret authority. An operator does not automatically need billing or tenant administration. The product standard is scoped authority.
Can permissions account for environment, region, or service sensitivity?
Infraveil's category requires environment-aware control. Production, staging, region, service tier, customer label, launcher host, and action class can matter. The platform direction is policy that understands context, not only user title.
What is encrypted at rest and in transit?
Infraveil's baseline is encrypted transport and protected persistence for sensitive operational data. The sharper answer is classification: secrets, tokens, signing material, audit records, telemetry, billing records, and support context do not all carry the same sensitivity or retention requirements. The platform treats those categories differently.
How do keys rotate without breaking production?
Infraveil treats rotation as an operations workflow. Rotation needs overlapping validity where appropriate, revocation, re-enrollment paths, audit records, and emergency procedures. A key model that cannot rotate safely is not production-grade.
What happens when a token, host, or user is compromised?
Infraveil's response model is containment first. Disable the user or session, revoke host enrollment, rotate workspace authority, invalidate scoped commands, preserve evidence, and review recent actions. The platform is designed to make authority visible enough to cut it off when needed.
Which subprocessors touch customer data?
Infraveil's position is that subprocessors must be named by function: infrastructure, payments, email, support, analytics, logging, or AI processing if used. Customers deserve a maintained subprocessor list and clear data categories rather than a vague trust request.
Can customers choose where data is stored?
Infraveil treats residency as an enterprise deployment question. Full residency requires regional control-plane choices, minimized cross-region movement, and clear separation between operational telemetry, billing, support records, and customer payload content. The platform does not pretend residency is solved by a sentence.
How long are logs, traces, audit events, and support data retained?
Infraveil's retention model is data-class based. Debug logs, audit records, security events, billing records, and support context have different purposes. The company standard is explicit retention by category, configurable retention where plans justify it, and no accidental forever-storage of sensitive support context.
Can a customer delete their data?
Infraveil separates active operational deletion from legal, tax, fraud, security, backup, and audit retention obligations. Customers can expect active workspace removal paths, export-before-delete thinking, token revocation, and clear retention boundaries for records that cannot disappear instantly by obligation.
How are backups tested?
Infraveil treats untested backups as assumptions. The operating standard is backup cadence, restore testing, recovery point expectations, recovery time expectations, and clarity about what data is covered. Recovery is part of the product's credibility.
What is the disaster recovery plan?
Infraveil's disaster posture covers the control plane, database recovery, customer communication, support continuity, and local launcher/agent behavior during central disruption. The runtime design matters here: customer services need continuity signals even when the central system is degraded.
Do you offer an SLA?
Infraveil does not use SLA language casually. Contractual uptime requires definitions, exclusions, measurement windows, customer responsibilities, support targets, and a distinction between Infraveil's control plane and customer infrastructure. The company answers with operational expectations first and contractual SLA terms when the plan supports them.
Do you provide a DPA and security questionnaire?
Infraveil treats DPA, privacy terms, subprocessor lists, and security questionnaires as part of selling to serious teams. Those documents must describe real controls. The company standard is not paperwork theater; it is paperwork that matches the product.
Has the platform been penetration tested?
Infraveil does not invent third-party test claims. Security maturity moves through internal review, dependency scanning, threat modeling, external assessment, remediation tracking, and recurring review. Formal test status belongs in the trust center when complete.
How do researchers report vulnerabilities?
Infraveil wants a clear security intake path, triage process, responsible disclosure expectations, and response timeline. A platform with customer-side runtime components benefits from responsible researchers, not silence.
How is software supply chain risk handled?
Infraveil treats supply chain as part of runtime trust: dependencies, build systems, release artifacts, install commands, payload delivery, signing material, and update behavior all matter. The platform direction includes pinned dependencies, scanning, signed artifacts where appropriate, and release records customers can reason about.
How do updates roll out safely?
Infraveil's release model is staged control, version visibility, rollback paths, compatibility awareness, and customer communication. The platform tracks launcher and agent versions, safe versions, deprecated versions, and recovery behavior if an update misbehaves.
How are production changes controlled?
Infraveil treats production change as evidence-bearing activity. Code review, deployment record, operator approval, rollout state, audit log, and rollback path belong in the same operational story. Speed matters, but speed does not erase accountability.
Does Infraveil need root access?
Infraveil documents privilege boundaries honestly. Some installation tasks can require elevated permissions depending on OS, service management, ports, users, or firewall configuration. Runtime authority narrows after setup: scoped users, explicit privileged actions, and no broad shell authority where it is unnecessary.
What outbound network access is required?
Infraveil's deployment story depends on predictable egress. Customers get the domains, ports, protocols, and endpoints used for launcher sync, agent payload fetch, telemetry, billing, support, and updates. Locked-down environments require allowlists, not guesswork.
Does the control plane require inbound access to customer servers?
Infraveil prefers management patterns that minimize inbound exposure. Launcher call-out models avoid opening broad inbound management ports. Application exposure, gateway behavior, and management authority remain separate concerns.
Can it run in an air-gapped environment?
Infraveil does not claim full air-gapped support unless the deployment model exists. Air-gap requires offline updates, local artifacts, private control-plane components, isolated identity, support procedures, and different licensing mechanics. The architecture can move toward that, but the claim stays scoped.
Can data be exported to existing observability or SIEM tools?
Infraveil does not need another stack above it to be coherent, but export remains customer control. Compliance archives, SIEMs, warehouses, and governance systems may still exist. Export does not weaken centralization; it prevents centralization from becoming opacity.
How does public status avoid lying?
Infraveil treats public status as evidence plus operator judgment. Status distinguishes maintenance, degraded performance, partial outage, customer-specific impact, dependency issue, and resolved state. Credibility comes from accurate classification, not optimistic color changes.
How does the platform avoid noisy incidents?
Infraveil reduces noise with thresholds, correlation, maintenance awareness, customer impact awareness, offline reason classification, and incident thresholds. A launcher offline event is not automatically customer impact. The platform escalates when evidence crosses a meaningful line.
What happens under legal hold or investigation?
Infraveil treats legal hold as preservation plus access control. Specific records may need preservation while unrelated customer data continues under normal retention. The product standard is to support evidence preservation without turning retention into unlimited data hoarding.
What is the customer still responsible for?
Infraveil centralizes operations, not legal ownership of the customer's backend. Customers remain responsible for application code, business logic, cloud accounts, operating system hygiene, data classification, compliance obligations, secret quality, and who they authorize. The platform clarifies responsibility; it does not erase it.
How do you prevent abuse of the platform?
Infraveil treats abuse prevention as platform safety. Account verification, billing checks, rate limits, suspicious activity detection, support escalation, shutdown procedures, and terms enforcement protect customers, infrastructure providers, and the control plane itself.
Is customer data used to train AI models?
Infraveil's answer must be explicit in product terms and contracts: assistant processing is not the same as model training rights. Customers need opt-out clarity, data-use boundaries, and separation between using AI to operate the workspace and using customer content to train models.
What is the one answer to all of this?
Infraveil does not ask customers to trust confident copy. It gives them a path to inspect the system: run the demo, connect a host, inspect launcher and agent source on the machine, watch control-plane behavior, test failure boundaries, read the docs, and challenge the trust model. Scrutiny is not a threat to the platform. It is the environment the platform is built for.