Public material explains control families, product boundaries, and responsible reporting without exposing private topology or customer data.
Security
Security has an operating boundary.
This page describes the public-safe security architecture and reporting routes Indwel can stand behind without converting design, source verification, or deployment configuration into a stronger assurance claim. Customer-specific commitments are established by the applicable written agreement and deployment authority.
Trust boundary
Security posture is specific to the estate and the evidence.
Managed, Dedicated, and Licensed estates assign operating responsibility through their written authority.
Security model
Indwel separates inference from institutional authority. Authenticated actors, tenant or workspace context, policy, Evidence, and explicit authority govern what an application may rely upon or cause. Action execution is treated more strictly than ordinary tool use because actions can affect external systems.
Public Ask Indwel is deliberately narrower than a customer estate. Its public authority does not include customer workspaces, private repositories, AWS administration, arbitrary web browsing, secrets, file uploads, or effectful tools. Customer deployments establish their own admitted identities, sources, capabilities, and authorities.
Perimeter, abuse, and capacity controls
The public Ask architecture requires layered controls around the service boundary, including CloudFront perimeter protection, WAF and rate controls, bounded anonymous sessions, concurrency and token ceilings, execution deadlines, provider-health and circuit authority, monitoring, and a service kill path.
Those mechanisms have deployment and release states. A configured, count-mode, shadowed, or source-verified control is not described here as universally enforced. Promotion into stronger enforcement requires the applicable live-access proof and release authority.
Data, secrets, and Evidence
Run inputs, Evidence, ledger entries, policy snapshots, and generated artefacts are not treated as customer data in business applications. Client applications must not embed privileged service credentials, and browser access must use admitted origin and authentication boundaries rather than permissive production defaults.
Security and operational telemetry should minimise raw sensitive payloads. Public Ask should not be used to submit confidential, privileged, regulated, or other sensitive information unless Indwel has expressly agreed that the service is configured to receive it.
Where governed file-evidence admission is enabled under the admitted AWS posture, objects enter through a controlled landing path and only an admitted clean result may promote material into evidence custody; failed, unsupported, or threatening scans do not silently become Evidence.
Continuity and recovery
Backup configuration, recovery design, and continuity controls are part of the operating estate, but configuration is not the same as a successful backup or restore. Stronger resilience claims require dated operational evidence for the estate to which the claim applies.
Failure isolation is also architectural: the static public estate is designed to survive an Ask outage or deliberate Ask shutdown, and customer deployments may use stronger isolation and custody patterns according to their deployment model.
Monitoring, telemetry, and privacy
Indwel’s security architecture includes logging, monitoring, rate and perimeter signals, verifier outcomes, redacted diagnostics, and security observability. The presence of a telemetry path does not itself prove period operating effectiveness.
Transport retention and durable analytics are separate privacy decisions. They require an admitted purpose, retention boundary, retention policy, and the applicable public or customer privacy terms.
Deployment responsibility
Managed places the service-operation burden principally with Indwel within the admitted managed envelope. Dedicated adds a customer-specific estate and stronger isolation while Indwel continues to operate the deployment. Licensed places materially more security, resilience, observability, release, and integration responsibility on the customer or operating partner.
Specific identity, networking, encryption, data-processing, support, recovery, security, and service commitments are established by the written agreement and deployment documentation. Public architecture does not silently create customer-specific obligations.
Report a vulnerability
Good-faith security reports may be submitted through the Contact page. Please include the affected surface, reproduction steps, and potential impact. Do not access, retain, alter, or disclose data beyond what is reasonably necessary to describe the issue.
The canonical public security policy is also published at /.well-known/security.txt.
Controls and assurance
The Compliance property is the public authority for current native-control, framework, implementation, evidence, testing, exception, and assurance projection. Its claim classes keep design and mapping, source implementation, current-source verification, live observation, operating-effectiveness testing, internal assurance, and external assurance distinct.
Security questions that require customer-specific topology, non-public evidence, contractual commitments, or restricted assurance material should proceed through Contact or the diligence path admitted by the current Compliance property.