What Is Embedded Data Governance? Why It Must Live in Workflows

---

Embedded data governance puts each control where the decision is made: the ticket, the pull request, the pipeline, the BI tool, the SQL editor, team chat and the AI agent’s tool call. A portal your team must visit governs only the people who visit it. Atlan, the Context Layer for AI, carries owners, definitions and classifications to many of those surfaces.

A control counts as embedded when four things hold:

• It runs in the tool where the decision happens.
• It runs on every path into that tool: the UI, the API and the agent.
• Its strength matches the risk, so it gates, nudges or only logs.
• One source of policy context feeds every surface, so copies do not drift.

Attribute	Detail
What it is	Governance controls that execute inside the tool where an access, change, classification or definition decision is made
Where it runs	Seven surfaces: ticket queue, pull request, pipeline, BI tool, SQL editor, team chat, AI agent tool call
Why it matters	DORA found no evidence that formal external review was associated with lower change fail rates; 118 interviews found staff build “shadow security” when the official route does not fit their work
Control types	Gate, nudge or log, chosen by whether the effect can be undone and by impact
Failure to test first	Enforcement that lives in one UI while API and agent paths bypass it
Open standards that help	ODCS v3.2.0 data contracts, OPA/Rego and Conftest policy checks, OWASP LLM06

---

What is embedded data governance?

Embedded data governance means the systems that handle data enforce governance requirements as part of their own operation, through code or configuration, instead of in a separate review step. The ODPi Egeria maturity model describes the embedded governance phase as one where “the technology that is managing data has the governance requirements directly encoded into its operations”.

Some teams use the phrase for something else: stewards placed inside business domains. That is an operating-model choice. The subject here is where the control runs. The two meet, though, because an embedded control needs an owner close enough to approve it.

The unit to govern is the decision. One table carries several: who may read it, how a column is classified, which definition of “revenue” applies. Each decision lands in a different tool and sits in one of three states:

• Embedded. The control executes in the decision surface, on every path, and shows its context.
• Adjacent. The control sits in the surface for the UI only, or fires without the context needed to act on it.
• Detached. The control lives in a portal, a document or a meeting.

Your governance operating model does not decide whether you can embed; teams on either side of the centralized versus federated data teams question can. At an agent’s tool call, the data access check and the agent’s permission check become one check. That is where data governance and AI governance meet.

---

Why does governance fail when it sits outside the workflow?

Three bodies of research describe the same handoff. None studies data governance directly, so read them by analogy.

DORA studied change approval in software delivery; a schema change in a pull request is the closest data equivalent. DORA’s capability guide on streamlining change approval says heavyweight external approval processes “have a negative impact on software delivery performance,” and that “no evidence was found to support the hypothesis that a more formal, external review process was associated with lower change fail rates.”

People route around controls that do not fit their work. In a 2014 UCL study of 118 in-depth interviews on security non-compliance with employees of a large multinational, researchers found staff building “shadow security.” These workarounds “are usually not visible to official security and higher management,” and they reflect “the best compromise staff can find between getting the job done and managing the risks.”

Too many prompts fail too. NIST’s 2016 research on security fatigue found that security fatigue can lead to “choosing the easiest option among alternatives” and “failing to follow security rules.”

The same pattern shows up in why governance implementations fail. An agent meets every detached control at once, which is how AI exposes governance debt. A review that runs once also misses what happens at run time rather than before deployment.

What primary sources say about where governance lives

Source	Exact wording	What it implies for placement
ODPi Egeria maturity model	“This can be done with code or configuration depending on the capability of the technology.”	Governance as code or configuration in the tools themselves
GDPR Article 25(1), Regulation (EU) 2016/679	“implement appropriate technical and organisational measures … and to integrate the necessary safeguards into the processing”	For personal data, safeguards are built into the processing itself
OWASP LLM06:2025 Excessive Agency	“Implement authorization in downstream systems rather than relying on an LLM to decide if an action is allowed or not.”	For agents, the control executes in the systems the agent calls
DORA, Streamlining change approval	“these approaches have a negative impact on software delivery performance”	External approval slowed delivery, with no evidence of lower change fail rates

In this Atlan session, Mastercard describes its approach to experience-first data governance.

---

Where are governance decisions actually made?

Seven surfaces are common, and each needs a different control. Access requests arrive in a ticket queue, so teams run access requests inside the ticketing system. Schema changes arrive as pull requests, where data contracts are checked before merge. The same check can run as a pipeline step before data lands.

In the BI tool, “can I trust this number” depends on the definition the tool uses, the job of a semantic layer. In the SQL editor, a sensitive column stays protected downstream when its classification follows it through lineage that carries context. The editor can show the classification, and masking belongs in the platform that runs the query. Team chat mostly delivers context: it governs which definition someone walks away with.

The placement map

Workflow surface	Governance decision made there	Embedded control that fits	What “detached” looks like	Source for the control pattern	Documented in Atlan docs
Ticket or request queue	Who may access which data, for what purpose	Approval routed to the asset owner, with a form for purpose; low-risk requests auto-approve	A generic governance queue with no named owner and no context on the data	Pattern; no standard needed	Access management workflow with approvals in Atlan’s inbox, plus forms; Jira ticket creation
Pull request	Is this schema or contract change safe; who downstream breaks	Contract-as-code checked in CI; an impact comment listing downstream assets and owners; peer review	Change merges, a dashboard breaks, the owner hears from a user	DORA: no evidence that formal external review was associated with lower change fail rates	Contract impact-analysis comment on the PR (Private Preview)
Pipeline or orchestration run	Should this run publish data that breaks a contract	The contract check runs as a pipeline step; a failing run stops before publish	A quality report arrives after bad data has landed	ODPi Egeria: “with code or configuration”	No Atlan doc cited; the contract check below runs in any CI or pipeline step
BI tool	Can I trust this number; is it certified; who owns it	Certification, owner and definition shown in the tool	The definition lives in a catalog tab the user has to open	ODPi Egeria: requirements “directly encoded into its operations”	Browser extension shows descriptions, owners, lineage and tags in supported data tools
SQL editor or query engine	May this query touch this column; is it sensitive	The editor shows the column’s classification; the query platform masks or filters restricted columns	The PII list lives in a document, separate from the query	GDPR Art. 25(1), for personal data: “integrate the necessary safeguards into the processing”	Tag propagation through lineage (off by default)
Team chat	What does this term mean; who do I ask	Definitions and asset links answered in-channel; workflow alerts in-channel	The question goes to whoever is online, with no link to the governed definition	Pattern; no standard needed	Slack and Teams integrations; Teams alerts for workflow activity
AI agent tool call	May the agent read or act on this asset; which definition applies	Authorization enforced in the system the agent calls; human approval for high-impact actions; agent reads the governed definition	Policy sits in a document the agent never reads; the agent decides permissions itself	OWASP LLM06:2025: “Implement authorization in downstream systems”	Atlan MCP: agents read governed definitions and lineage; answers are “governed by the permissions you’ve already set in Atlan”

AI agents are a workflow surface too

An agent’s tool call is a decision point with no human pause in it. OWASP LLM06:2025 names three root causes of excessive agency: “excessive functionality,” “excessive permissions” and “excessive autonomy.” Its guidance is to “Implement authorization in downstream systems rather than relying on an LLM to decide if an action is allowed or not.”

That puts AI agent governance in the systems the agent calls. Giving agents access to enterprise data safely means agent access control at the data layer, which still decides what a SQL query can read. A context layer supplies the definitions and classifications that policy is written against. Role-based access control in the context layer decides what the agent sees there.

Identity matters here. With Atlan MCP over OAuth, each person signs in with their own Atlan account, so “tools run with their own permissions.” An API key is “a single static token that acts as one shared identity.” Give that key only the access its callers need.

---

When should a governance control gate, nudge or only log?

Ask two questions. Can the effect be undone? How much damage does a wrong call do? Disclosure, external sharing and deletes cannot be undone. Edits and revocable grants can.

NIST’s security fatigue research found that fatigue can lead people to choose the easiest option and stop following security rules. So keep prompts rare. Carry context everywhere, and gate only high-impact actions that cannot be undone.

The gate, nudge or log matrix

	Can be undone (edits, revocable grants)	Cannot be undone (disclosure, external sharing, deletes)
High impact (restricted data, regulated data, certified metrics)	Nudge. Warn in-surface with the owner and definition, then log. Example: changing the definition of a certified metric. Grounding: NIST security fatigue	Gate. Block until an owner approves, in the surface. Examples: reading unmasked restricted columns; exposing a restricted column externally; letting an agent delete restricted data. Grounding: OWASP LLM06, “require a human to approve high-impact actions before they are taken”
Low or medium impact (internal or public data)	Log only, or auto-approve by rule. Review in aggregate. Examples: editing a description; access to an internal, non-sensitive dataset. Grounding: DORA, peer review plus automation over heavyweight external approval	Gate with auto-approval rules. Example: dropping an internal, non-sensitive table, gated in your pipeline or warehouse change process. For requests that run through Atlan, governance workflows support autoapproval rules for users, groups or owners based on metadata attributes and policies

In the gate cell, a person approves each action. Everywhere else people sit on the loop. They set the rules and review the log, and agent guardrails apply between reviews. The gate row is where governed and ungoverned agent access differ. A log helps only if it records why an action was allowed, which is what decision traces capture.

---

What goes wrong with embedded data governance?

Thirteen failure modes recur. F1 to F9 come from governance that was never embedded, or was embedded badly. F10 to F13 appear later, once people actually use the controls.

On the agent side, governance rules readable by AI agents address F5, and zero trust data governance addresses F6, because the client is never trusted to enforce. F7 is the access version of what teams hit when they fix quality problems at the source. F8 shows up in data quality use cases where governance fits, as a check that fails without saying what to do. F9 is context drift applied to rules.

Thirteen failure modes and their fixes

#	Failure mode	Why it happens	Fix
F1	The portal nobody visits. Policies and definitions live on a separate site; usage stays with the governance team.	Common pattern; no study cited	Push context to the surface; measure use at the surface, not portal logins.
F2	The external approval board. Every change waits for a committee outside the team.	DORA: “no evidence was found to support the hypothesis that a more formal, external review process was associated with lower change fail rates”	Peer review in the PR plus automated checks; keep committee review for policy changes.
F3	Shadow governance. People who cannot comply with the official route build their own.	UCL, 118 interviews: workarounds “are usually not visible to official security and higher management”	Treat workarounds as requirements, then make the governed path the shortest one.
F4	Approval fatigue. Every action prompts, so people stop reading the prompts.	NIST: fatigue leads to “failing to follow security rules”	Gate only high-impact actions that cannot be undone; nudge or log the rest; auto-approve low-sensitivity requests.
F5	Policy the agent cannot read. Rules exist as prose; the agent infers permission.	OWASP LLM06: “excessive functionality,” “excessive permissions,” “excessive autonomy”	Machine-readable classifications and definitions; authorization in the system the agent calls; human approval for high-impact actions.
F6	UI-only enforcement. The control lives in one client, so API, SDK and agent paths bypass it.	OWASP LLM06: authorization belongs “in downstream systems”	Enforce at the server or data layer; test the API and agent path explicitly.
F7	Classification that stops at the source table. The PII tag sits on the raw column and not on the derived one.	Lineage is not used to carry the tag	Propagate classifications through lineage and hierarchy, and check it is switched on. In Atlan, tag propagation is off by default.
F8	A gate with no context. CI fails with “contract violation” and no owner, impact or fix.	Common pattern; no study cited	Every block names the rule, the owner, the downstream impact and the fix in the same surface.
F9	Embedded copies drift. Each tool holds its own copy of the rule or definition.	Common pattern; no study cited	One source of policy context, delivered to many surfaces; no hand-kept per-tool copies.
F10	Rubber-stamp approvals. Owners approve nearly everything, nearly instantly, because the request gives them nothing to judge.	Common pattern; no study cited	Put purpose, classification and downstream use in the request. Move request types that are always approved into auto-approval rules. Signal: approval rate and time to decide, per owner.
F11	Owner bottleneck. Requests wait on one overloaded person, or on an owner who has left.	Common pattern; no study cited	Name a delegate, set a response-time target and an escalation path. Signal: wait time and the share of requests open past the target.
F12	Ignored warnings. A nudge fires so often that people dismiss it without reading.	Common pattern; no study cited	Retire or retarget nudges that are almost always dismissed; promote the ones that guard irreversible actions to gates. Signal: dismissal rate per warning.
F13	Widening auto-approval rules. Each exception widens a rule until the gate decides nothing.	Common pattern; no study cited	Review auto-approval rules on a schedule, with the owner signing off on changes. Signal: the share of requests auto-approved, over time.

---

How to embed a governance check in a pull request

A data contract checked by policy-as-code in CI puts the governance decision in the pull request, where the change is proposed. The same check can run as a pipeline step before data is published. The example uses three open projects: the Open Data Contract Standard, whose “current version is v3.2.0,” OPA’s Rego policy language in v1 syntax, and Conftest to run it.

A contract-as-code example

The values are illustrative and the field names are real. ODCS does not fix the classification vocabulary, so public, internal and restricted are this example’s choice.

contracts/customer_orders.odcs.yaml:

apiVersion: v3.2.0
kind: DataContract
id: 7d1c2f0e-0000-4000-8000-000000000001
name: customer_orders_v1
version: 1.0.0
status: active
domain: sales
schema:
  - name: customer_orders
    physicalType: table
    properties:
      - name: order_id
        logicalType: string
        primaryKey: true
        classification: public
      - name: customer_email
        logicalType: string
        classification: restricted
      - name: order_total
        logicalType: number
        classification: internal
team:
  name: sales-data
  members:
    - username: owner-placeholder
      role: Owner

policy/contract.rego holds two rules. The first denies any column with no classification. The second denies a restricted column when the contract names no Owner.

package main

deny contains msg if {
  some table in input.schema
  some col in table.properties
  not col.classification
  msg := sprintf("%s.%s has no classification", [table.name, col.name])
}

deny contains msg if {
  some table in input.schema
  some col in table.properties
  col.classification == "restricted"
  not has_owner
  msg := sprintf("%s.%s is restricted but the contract names no Owner", [table.name, col.name])
}

has_owner if {
  some m in input.team.members
  m.role == "Owner"
}

Run it in CI on every pull request:

conftest test contracts/customer_orders.odcs.yaml --policy policy/

This contract passes both rules. To see one fail, change the team block so nobody holds the Owner role:

team:
  name: sales-data
  members:
    - username: steward-placeholder
      role: Data Steward

The first rule still passes, since every column has a classification. The second rule fails on customer_email: it is restricted and no member has role: Owner, so the rule’s message names customer_orders.customer_email and what is missing, in the pull request the author already has open. That is a start on F8: the message names the column and the missing role. The rule cannot tell whether the named Owner is a real, current person. Test both versions in a dev repo before you wire the check into CI.

Contracts versioned and reviewed like code are part of the context development lifecycle; for a wider program, follow a 12-month shift-left timeline.

---

How do you check whether a governance decision is embedded?

Run these 15 questions against each governance decision (access, classification, change, definition, certification). Each item names the failure mode a “no” points to.

The 15-point embed check

1. Can you name the surface where the decision is actually made (ticket, PR, pipeline, BI tool, SQL editor, chat, agent)? (F1)
2. Does the control execute in that surface, or does the person have to leave it? (F1)
3. Does the control execute on the API, SDK and agent path as well as the UI path? Test it. (F6)
4. Does a block or warning name the rule, the owner and the fix in the same surface? (F8)
5. Is the control type matched to risk and reversibility (gate, nudge or log)? (F4)
6. Are low-risk requests auto-approved? (F2, F4)
7. Is the policy machine-readable (classification, definition, contract), not only prose? (F5)
8. Does the classification follow the data downstream, with propagation switched on? (F7)
9. Is there one source of policy context, or per-tool copies? (F9)
10. Do you know of workarounds for this decision (shadow governance), and have they become requirements? (F3)
11. Can you measure use at the surface (requests, PR checks, in-tool views) instead of portal logins? (F1)
12. Do you track each owner’s approval rate and time to decide? (F10)
13. Does every gated decision have a current owner, a delegate and a response-time target? (F11)
14. Do you track how often each warning is dismissed? (F12)
15. Do you review auto-approval rules on a schedule, including the share of requests they approve? (F13)

Any “no” on items 2 or 3 means the decision is Adjacent or Detached. Items 12 to 15 apply once a control is live. Fix Detached decisions that cannot be undone and touch restricted data first.

Run it per domain as you scale governance across domains. Items 11 to 15 supply the numbers for the ROI case for governance.

---

How Atlan carries policy context into your workflows

Atlan, the Context Layer for AI, keeps one governed source of owners, definitions, classifications and approval rules, and delivers it to many of the surfaces above. That is the job of a context layer for governance teams, and keeping it current is context engineering applied to policy.

In BI and data tools. Through the browser extension, owners, descriptions, lineage and tags appear in a sidebar “directly inside your supported data tools.”

In team chat, the Slack integration shares assets and sends notifications in-channel; Microsoft Teams also sends alerts for “Workflow activity and playbook runs.”

In the ticket queue. Four templates (Change management, New entity creation, Access management, and Policy approval, which needs the policy center module) give you workflows that “run in the background, make sure that all required approvals are in place”. Approvers act in Atlan’s inbox. Forms that collect structured request details can be embedded in the Access management and New entity creation templates, and the Jira integration automates ticket creation. If your requests already live in a ticketing system, decide which system holds the approval record, or you have built a second queue.

Know the gap. Workflows are not triggered for bulk updates through the API, SDK or CLI, playbooks, spreadsheet tools or Atlan AI, or for metadata updates made through the browser extension. On those paths that is F6, so test them as item 3 asks.

In the pull request. Contract impact analysis posts a comment on the pull request for each changed contract file, listing impacted assets with descriptions, owners and linked glossary terms. It is in Private Preview. Treat it as context for the reviewer; the contract check above is the gate.

Downstream, tag propagation carries tags, such as a PII tag, through lineage and from parent to child assets. It is off by default.

For agents. Atlan MCP lets AI tools “search enterprise context, traverse end-to-end lineage, read governed definitions, and run SQL,” and it is “hosted and enabled for all Atlan tenants.” Answers are “governed by the permissions you’ve already set in Atlan.” With an MCP-connected catalog, the agent reads the same governed definitions people use, kept current through context engineering for AI governance. Implementing an enterprise context layer covers the rollout.

---

Start with the decision you cannot undo

Embedding every control at once recreates the fatigue it was meant to remove. Pick the restricted-data decision your team makes most often that cannot be undone, find its surface, and run the check on it.

Then test the API path: try to make the same change through the API that your UI blocks. A month after go-live, look at items 12 to 15 and ask whether the approvals still mean anything.

---

FAQs about embedded data governance

1. How is embedded data governance different from traditional data governance?

Traditional governance reviews data decisions through committees, portals and policy documents, often after the fact. Embedded governance encodes the requirement into the tools that handle the data, so the control runs at the moment of the decision, in code or configuration.

2. What is the difference between embedded governance and shift-left governance?

Shift-left governance moves checks upstream, to the producers who create and change data. Embedded governance covers every surface where a governance decision is made, including BI tools, SQL editors, team chat and AI agent tool calls. Shift-left is the producer side of embedding.

3. Does embedded governance mean more approvals?

Not if you place them by risk. Gate only high-impact actions that cannot be undone, such as reading restricted data. Actions that can be undone get a warning or a log entry, and low-risk requests auto-approve. NIST’s security fatigue research found that asking people to make more security decisions than they can manage leads to fatigue, and fatigue leads to failing to follow security rules.

4. Is embedded governance required by regulation?

For personal data covered by GDPR, Article 25 points this way. It requires controllers to integrate the necessary safeguards into the processing, both when the means of processing are decided and while the processing runs. For other data, check the rules that apply to you.

5. What tools support embedded data governance?

Three categories of tools help. Contract standards such as ODCS define the rules as code. Policy engines such as OPA and Conftest check them in CI or a pipeline step. Both work without any catalog. A context layer such as Atlan delivers definitions, owners and classifications to each surface.

---

Sources

1. Streamlining change approval, DORA
2. Learning from “Shadow Security”: Why understanding non-compliance provides the basis for effective security, UCL Discovery
3. ‘Security Fatigue’ Can Cause Computer Users to Feel Hopeless and Act Recklessly, New Study Suggests, NIST
4. LLM06:2025 Excessive Agency, OWASP Gen AI Security Project
5. Embedded Governance, ODPi Egeria Open Metadata and Governance maturity model
6. Regulation (EU) 2016/679 (GDPR), EUR-Lex
7. Open Data Contract Standard, Bitol (LF AI & Data)
8. Policy Language, Open Policy Agent
9. Upgrading to v1.0, Open Policy Agent
10. Conftest, Conftest
11. Use Atlan browser extension, Atlan Docs
12. Slack, Atlan Docs
13. Use Atlan in Microsoft Teams, Atlan Docs
14. Jira, Atlan Docs
15. Automate data governance, Atlan Docs
16. Create forms, Atlan Docs
17. Add contract impact analysis in GitHub, Atlan Docs
18. Tag propagation, Atlan Docs
19. Set up Atlan MCP, Atlan Docs