Vidabug
Trust, transparency & governance / Security & Trust Statement

Security & Trust Statement IN EFFECT

Clear commitments and honest implementation status

1. Security philosophy

Vidabug is intended to separate customer identity, source ingestion, authorised engineering execution, AI inference, billing and deliverable release. Customer code is treated as sensitive and untrusted; agent output is treated as evidence requiring review.

Design intentions described here are not certifications. Specific controls will be marked ‘implemented’, ‘pilot’ or ‘planned’ in a signed enterprise security schedule.

2. Identity and least privilege

Approved target: multi-tenant role enforcement, MFA or SSO for enterprise users, encrypted server-side repository grant storage, revocable scoped tokens and administrative access logs.

Repo read permissions and code-writing permissions must remain separate. A user-visible ‘connected’ badge is not proof of a successful security assessment.

3. Execution isolation and client protection

Each production runs in its own isolated cloud machine with an exact snapshot of the code, a limited outbound network (package registries and named hosts only), synthetic test identities and a hard spending cap. Repository tokens never enter the machine; fixes are pushed only to a dedicated branch and offered as a pull request. Merges, production writes and security-sensitive actions stay with the customer.

Malicious source or prompt-injection content must not be treated as instructions. Secrets and raw event logs must not be streamed to clients.

4. Evidence integrity and disclosure

Maintain SHA-256 file manifests, immutable source revision references, redacted event timelines, repair patch provenance and reviewer decisions. Report ‘independently verified’ only when an independent authorised check and matching evidence exist.

Security issues can be sent to a monitored contact published on the Company & Legal Notices page. The vulnerability disclosure process will define scope, safe harbour where agreed and triage timelines before launch.

5. Incident response and transparency

A formal incident plan will cover investigation, preservation, containment, affected-customer notification, operator reporting and restoration. Reporting duties are jurisdiction-specific.

No false claims of SOC 2, ISO certification, GDPR readiness, 100% security, 256-bit end-to-end encryption, zero training or local data residency should appear in public marketing without current evidence.

STYLE