Compliance

Compliance lets you measure how your workspace tracks against the standards that matter to your organization. It is driven by rulesets. Any ruleset you add to a workspace, whether it represents a regulatory framework, security standard, coding guideline, or internal policy, becomes something you can measure compliance against.

Rulesets as the foundation

Rulesets are what power compliance. When you add a ruleset to a workspace, it defines a set of rules the agent follows when generating code and responding to conversations. Compliance takes this a step further by tracking how well the workspace adheres to those rules over time.

This means compliance is as flexible as rulesets themselves. You can measure against anything you can express as a ruleset.

  • Regulatory frameworks like SOC 2, ISO 27001, HIPAA, or PCI DSS
  • Security standards like CIS benchmarks or your organization's security policies
  • Coding standards like naming conventions, module structure, or tagging requirements
  • Internal policies like deployment patterns, approval workflows, or documentation requirements

If you can write it as a ruleset, you can track compliance against it. To learn how to create and manage rulesets, see Rulesets.

Controls

Each ruleset consists of individual rules. In the context of compliance, these rules act as controls, the specific requirements that need to be satisfied. For example, a SOC 2 ruleset might include controls around access management, encryption at rest, logging, and change management. A coding standards ruleset might include controls around naming conventions, variable structure, and module sourcing.

Within a workspace, you can see which controls are mapped, their current status, and any evidence or artifacts associated with them. This gives you a single view of where you stand for a given set of standards without leaving the workspace.

Evidence

As you work in the workspace, activity like code changes, agent conversations, and configuration decisions can serve as evidence for compliance controls. The workspace keeps a record of what happened, when, and who was involved. This makes it easier to pull together what you need during an audit instead of scrambling to reconstruct it after the fact.

How it fits together

Compliance is scoped to the workspace because each workspace represents a distinct project or piece of infrastructure. Different projects may be subject to different standards. A workspace running a payments service might need PCI DSS and strict security controls, while a workspace managing internal tooling might only need SOC 2 and your organization's coding guidelines.

Rulesets flow into compliance from multiple levels. Enterprise rulesets that are marked as required apply everywhere automatically. Optional enterprise rulesets can be toggled on per workspace. And workspace-specific rulesets let you add standards that are unique to a particular project. All of these feed into the compliance view. See Rulesets for more on how rulesets work across enterprise, workspace, and user levels.

Evaluation and CI

Compliance evaluations can be triggered manually from the workspace, automatically after agent sessions, or as part of your GitHub CI pipeline on every pull request. For details on how evaluations work, overrides, CI compliance checks, and enterprise compliance settings, see Enterprise Compliance.