Controlled-preview architecture

The intended customer-side collection, hosted decision layer, data-flow boundary, approval, and verification model.

IMPLEMENTATION AND DESIGN EVIDENCE ONLY. Shielda is in controlled preview. This page does not claim a production-ready system, a generally available agent, certified deployment, supported integration catalog, or completed customer outcome.

Product model

Shielda is designed to turn security observations into reviewable decisions and bounded next actions. The model keeps five stages distinct:

1. Observation — record evidence, provenance, freshness, and uncertainty.
2. Decision — relate the observation to an authorized system, owner, and business context.
3. Prepared action — name the exact target, expected effect, limits, rollback, and verification plan.
4. Approval and execution — preserve the approving person and the exact operation they authorized.
5. Independent verification — collect a new observation that can confirm, reject, or qualify the intended outcome.

A scanner result is not automatically true. A ticket, pull request, provider response, merge event, or manual “done” state is not by itself a verified security outcome.

Intended deployment boundary

Customer environment

The planned customer-side agent inspects only an explicitly authorized scope. Public installation artifacts and a generally available runnable scanner catalog are not currently offered.

Outbound coordination

The design favors customer-initiated outbound communication with a control plane rather than an inbound management port. The exact endpoint, transport, authentication, payload, and network requirements must be documented and tested for the evaluated release. This page does not make a blanket mTLS or network-isolation claim.

Control plane and data egress

Selected inventory, scanner output, findings, evidence, decisions, model input, and operational records may leave the customer boundary and be processed or stored by a control plane or external provider. The exact data classes and destinations depend on the approved workflow and deployment.

Identity, model inference, cloud, source control, billing, email, and observability paths can add processing or egress. An SDK, environment variable, UI label, or source adapter does not prove a provider is active, approved, or supported.

Review required before access

For a controlled preview, request an exact data-flow and permissions schedule that identifies the deployment, authorized targets, data categories, providers, regions, storage, retention, deletion, human approvals, supported operations, and verification method.

Do not assume self-hosting, BYOK, customer-managed keys, regional hosting, local-only processing, zero retention, tenant-isolation certification, or connector support from code paths or historical diagrams.

See the public architecture page and current trust status.