Security and data handling

This article documents the security posture of Yig at a level intended for security reviewers, compliance officers, and finance leaders evaluating the system. It pairs with the Architecture overview and the HITL design principle.

Data residency

Customer data does not transit a vendor data plane.

• Yig reads customer data from the customer’s own systems (warehouse, spreadsheet, document store, ERP) at the moment a workflow runs, scoped to that workflow.
• Yig writes drafts and approved outputs back into the customer’s own systems.
• Yig does not maintain a copy of customer financial data between runs.

There is no Yig-hosted database of customer ledgers, journals, schedules, or working papers. This is structural, not configurable.

Deployment topologies

Three supported patterns:

Topology	Where the agent runs	Where data is read/written	When to choose
Local	Operator’s machine	Operator’s local files	Single user, regulated environments, evaluation
Customer cloud	Customer’s cloud account	Customer’s systems	Team deployments, internal compliance
Single-tenant managed	Dedicated, isolated environment	Customer’s systems via egress only	Customers who prefer not to operate the runtime

Multi-tenant managed deployment is intentionally not on this list. It will be considered as a separate architecture, with separate guarantees, if and when we ship it.

The model contract — BYOK

Yig is bring-your-own-key.

• The customer holds the inference contract with the model provider.
• The customer can substitute Claude, a frontier alternative, or a self-hosted model without changing workflow definitions.
• The customer controls the data-handling clauses of that contract directly with the provider.

This means there is no Yig-side opportunity to train on customer data, retain prompts, or cache model outputs in our infrastructure. The model provider’s terms apply, not ours.

The audit log

Every Yig run produces an append-only audit record. The record contains:

• A run identifier (stable, time-ordered).
• The instruction received and the workflow invoked.
• The tools called, their input shape, and their output shape.
• Each draft produced and the reviewer it was presented to.
• Every reviewer action (accept, reject, edit, comment) with timestamp.
• The diff between the draft and the shipped artefact.
• The model provider and identifier used (not the API key).

The audit log is the source of truth for what happened during a run. It is designed to be sufficient evidence for a downstream audit — internal or external — without requiring access to the agent runtime.

The log is written to a destination the customer controls (object storage, log pipeline, file system). Yig does not retain a copy.

The reviewer gate

No output reaches L4 (the customer’s systems) without a reviewer record in the audit log. This is enforced at the architectural layer, not at the application layer.

A workflow that completes without an approval is logged, kept as a draft, and not shipped. The agent does not have a “skip review” mode.

What we do not do

These are commitments, not toggles:

• No training on customer data. Yig does not fine-tune models on customer prompts, outputs, or audit data. The BYOK model means we are not in a position to do so even if asked.
• No telemetry by default. A self-hosted Yig deployment does not phone home for analytics, error reporting, or usage metering. Optional crash reporting, when added, will be an explicit, scoped, off-by-default toggle.
• No background automation. A workflow does not execute without an instruction from an authenticated operator. The agent cannot self-trigger.
• No undisclosed data sharing. If we ever need to handle customer data outside the four-layer model — e.g. to support a debugging session — it requires a written, scoped, time-bound authorisation from the customer for that specific incident.

If any of these change in a future version of the product, the change will be announced before the version ships, here in /docs/security.

Open items we will publish

Security is not a one-time statement. The following are tracked items we will publish as they are completed:

• Reference deployment guide for local and customer-cloud topologies.
• Reviewer-role taxonomy and authorisation rules for team deployments.
• Audit-log schema specification (machine-readable).
• Recommended retention and rotation policies for the audit log.
• Pen-test summary, when commissioned.
• SOC 2 / ISO 27001 evidence map, when applicable.

If your security review needs an item not yet on this page, write to support@yigcore.com and tell us what you need. We will either send you the document under NDA or add it to the publication queue.