Start from the frameworks you are measured against
The posture view is where a compliance lead opens obstruo: which obligations are in scope, which controls cover them, and which evidence is already being collected in path. Every card below links to the records that support it, so a reviewer does not have to ask an engineer for a screenshot.
Write the rule once, in the catalog
Governance teams keep every rule in one catalog: what it does, which projects it reaches, and how strongly it binds them. Locked policies cannot be edited inside a project. Recommended ones can be declined with a reason. Optional ones are there for teams that want them. Each change produces a new version with a diff and an author, and a request is always evaluated against the version that was active at the time.
One standard per jurisdiction, not per team
A redaction standard says which categories of personal data are stripped, how they are tokenized, and what happens when detection cannot run. Compliance owns the standard, engineering only picks which one a project inherits. A prompt from Germany leaves with GDPR-grade redactions, the same prompt from California gets CCPA-grade, and the standard that applied is written into the record.
Separate the people who propose from the people who approve
Governance work only holds up if the roles are split. Policy authors propose, compliance approves, platform teams operate, and auditors read. Administrative activity is recorded per action, so a policy edit or a key rotation has a name and a timestamp attached to it.
Every agent, MCP server and skill in one registry
The registry is where governance teams see what exists: owners, risk ratings, data sources, tools and coverage. MCP servers are governed today. Agents and skills are next, discovered from real live traffic rather than a questionnaire, so the register reflects what is actually running.
Owners, risk, data sources, tools, and approvals in one registry. Auto-discovered from live traffic.
Trust, transport, auth posture, and per-tool permissions. Flag destructive tools before an agent connects.
Source, bundled scripts, and the capabilities each skill is allowed to use. Approve code execution and egress.
Know which processor saw what, before the auditor asks
Every provider and MCP server your organisation uses is a processor or a sub-processor. The register keeps the contract state, the processing region and the data categories allowed for each one, and connects them to the projects and agents that actually call them. When a provider is added in the console, it appears here, not in a spreadsheet three quarters later.
Approval queues, incident linkage, retention, framework mappings and evidence exports are all views over the same audit record. They have their own page, because that is the part an auditor reads.
Not built yet, and labelled that way
Two governance surfaces are in progress. They are on this page so your review can plan around them, not so a sales deck can imply they exist.
One picture of what your AI can currently reach: which data sources feed which agents, which tools those agents hold, and which processors sit on the other side. Built from real live traffic rather than a questionnaire, so it shows exposure as it is, not as it was designed.
Impact assessments started from what the registry already knows about a project, and data-subject requests answered against the redaction and retention state of real traffic. The intent is that a DPIA stops being a document written from memory.