Work with an agent

Use your agent to prepare and maintain the map before either the CI or local publication workflow. The agent reads schemas and the code that uses them, proposes classifications and processing purposes, and explains the evidence. You decide whether those interpretations are correct.

Choose an approach

The interactive steps below use your existing agent environment. For automated preparation, see Run an agent as a CI bot.

Prerequisites

Install the Noru privacy plugin (privacy-datamap in Noru GRC Engineering) using its installation instructions for your agent. Open your application's local Git checkout in the agent. It can be hosted on GitLab, GitHub, or another Git host. Follow the plugin's runtime requirements.

Preparing and reviewing a map needs no Noru connection. To compare or publish through the agent, configure a Noru MCP connection for the intended organization with read:organization, read:datamaps, and, for publication, write:datamaps. Installing the plugin and connecting to Noru are separate steps. The plugin is also separate from the privacy GitHub App used for connected repository scanning.

For CI or shell publication, complete the local and CI prerequisites. The rest of this page refers to the Noru privacy plugin as “the plugin”.

Ask for a proposed map

With the plugin installed and your application checkout open, ask:

Use the Noru privacy plugin to scan this repository and prepare a data map
for review. Trace how fields are used, not just their names. Show proposed
personal and non-personal classifications, processing purposes, source-code
evidence, and any unanswered questions or coverage gaps. Preserve existing
accepted decisions where their evidence is unchanged. Do not publish yet.

In agents that expose the plugin's slash commands, /privacy-datamap:scan starts this workflow. Collection alone produces a starting structure; the agent must also investigate code usage and complete the review proposals. Ask it to show the review grouped by datastore and collection, including changed processing activities and anything it could not establish.

Review and record the decisions

Check the proposed categories and purposes against the code evidence and what your business actually does. An ID or timestamp can be personal when it relates to a person; its name alone is not enough to classify it. Confirm genuinely non-personal fields so they remain tracked locally without entering the personal-data export. Resolve ambiguities and coverage gaps before acceptance.

Name the accountable reviewer and specify how long the review remains valid. For example, after inspecting the proposal:

I accept the classifications and purposes in the reviewed customer-service
proposal. Record me, [reviewer name], as the accountable reviewer for 90 days.
Apply those decisions, validate the map, seal the accepted baseline, and
regenerate the Fideslang export. Run the offline privacy check and show me
the resulting diff before committing or publishing.

The agent records the named decisions in .noru/privacy-datamap.yml, seals .noru/privacy-datamap.lock.json, and generates .fides/datamap.yml. Review and commit these files with the source changes they describe. Proposed analysis in .noru/.cache/ stays out of version control. Acceptance of a classification is separate from permission to publish it.

Choose how to publish

• CI/CD: commit the reviewed files and use the pipeline workflow. The agent prepares the change; CI checks the accepted map and publishes after merge.
• Local API call: use the curl walkthrough. If the agent has already generated and checked the files, continue at Build the request body.
• Through your agent's Noru connection: ask for /privacy-datamap:diff to preview what would change in the connected organization. Review the destination and create/update counts, then explicitly authorize /privacy-datamap:push. The plugin checks that the reviewed plan is still current before writing. Ask for another diff afterwards to verify there are no outstanding changes. This route uses MCP rather than the REST API key in CI.

Choose one publication route for the source so independent jobs do not overwrite one another. When code changes later, ask the agent to investigate the new proposals and changed evidence. Review those changes, refresh the accepted files, and rerun the check. An expired review needs a renewed human decision; the agent must not clear a flag or refresh an approval simply to make CI pass.

Run an agent as a CI bot

Use a CI bot to automate the preparation work you otherwise request in a chat. Implement it as a pipeline job that runs when code changes or on demand; a separately deployed service is optional. The bot investigates changes and prepares a reviewable proposal, while a person remains accountable for accepting privacy decisions.

The outlines below describe how to assemble this workflow using an agent runner, the plugin, and your repository platform. The runner performs analysis; the existing privacy check and publisher validate and send the accepted files.

Configure the runner

Configure the runner with the application checkout, the plugin's instructions and tools, and a configured model provider and model. An OpenAI or Anthropic API key can power the analysis. Store it in the CI secret store and supply it only to the agent job. Choose a model provider supported by your runner and follow its configuration instructions.

Add repository integration to open or update a merge request (GitLab) or pull request (GitHub). A bot account or appropriately scoped repository credential authorizes those changes. If the integration cannot write proposals to the repository, configure it to produce an artifact for a developer to review and apply locally instead.

Source-code excerpts may be sent to the selected model provider. Choose a provider and configuration consistent with your organization's requirements. Run secret-bearing jobs in a trusted environment; proposed repository changes must not gain access to credentials by changing the runner's instructions or executing arbitrary code.

GitLab CI approach

Use a trusted pipeline definition in .gitlab-ci.yml to run the agent and produce a merge request for the privacy changes.

1. Configure secrets. Store the model-provider key and a suitably scoped bot credential under Settings›CI/CD›Variables. Mask secrets and restrict their availability. Protected variables normally require a protected branch or tag; do not assume an ordinary merge request pipeline can access them. See GitLab CI/CD variables.
2. Start preparation. Initially, use a maintainer-triggered pipeline on a protected branch with the target merge request and exact commit as inputs. Load the runner from trusted configuration and inspect the target checkout as source material. For automatic merge request triggers, keep the same separation between trusted runner configuration and the code being analysed.
3. Produce the proposal. Have the runner investigate the code and create or update a bot-owned branch and merge request containing the proposed map changes, evidence, and unresolved questions. Link it to the source change and keep both aligned before merging. If repository writes are unavailable, save a pipeline artifact for a developer to apply.
4. Review and check. Record the explicit privacy acceptance described below, regenerate the accepted files, and require the offline privacy check before merge. A GitLab approval by itself does not populate the privacy manifest.
5. Publish. After merge, run the existing check and publisher on the protected default branch, with NORU_API_KEY available only to the publication job. Follow the GitLab CI tab in the publication guide.

A trusted automation project is another option if the application project's pipeline cannot safely access the preparation credentials. Configure its repository access and proposal delivery as part of your runner integration.

GitHub Actions approach

Use a workflow under .github/workflows/ to run the agent and produce a pull request for the privacy changes.

1. Configure secrets. Store the model-provider key in Actions secrets, and use a repository-authorized GitHub App installation token or another appropriately scoped credential for bot branch and pull request writes. Keep the Noru publication key separate from preparation.
2. Start preparation. Initially, use a manually dispatched workflow (workflow_dispatch) with the target pull request and exact commit as inputs. Use a trusted workflow and runner implementation; treat the target checkout as source material. Do not use a privileged pull_request_target workflow to execute untrusted pull request code.
3. Produce the proposal. Have the runner create or update a bot-owned branch and pull request with the map proposals, evidence, and unresolved questions. Link it to the source change and keep both aligned before merging, or upload an artifact when repository writes are unavailable.
4. Review and check. Record explicit privacy acceptance, regenerate the accepted files, and require the offline privacy check through repository rules. Ensure the bot's commits trigger that check: events created with GITHUB_TOKEN generally do not start another workflow. Use an appropriate App token or an explicit dispatch where needed. See GitHub workflow triggers.
5. Publish. On a push to the default branch after merge, run the existing check and publisher with NORU_API_KEY exposed only to publication. Follow the GitHub Actions tab in the publication guide.

Both approaches use your configured agent runner and repository adapter. The model-provider key powers analysis; the repository integration delivers the proposal for review. The following acceptance and publication rules apply to both providers.

Prepare a proposal and obtain review

Structure the pipeline as follows:

1. Collect current structure and reconcile it against the accepted privacy baseline.
2. Run the agent to investigate new fields and changed processing evidence, preserving accepted decisions whose evidence remains current.
3. Prepare proposed classifications, purposes, code references, and unresolved questions. Open or update a merge request containing the proposal for review.
4. Have an accountable reviewer explicitly accept the privacy decisions and specify their validity period. A generic merge request approval alone does not record the named privacy decisions required by the plugin.
5. Apply the accepted decisions, validate the manifest, seal the accepted baseline, and regenerate the Fideslang export. Commit those reviewed files to the change and run the offline check before merge.

Bind acceptance to the exact proposal reviewed. If relevant code or evidence changes, the affected decisions need review again. The bot must not approve its own proposals, clear unresolved flags, or renew expired approvals just to make CI pass. If your runner does not integrate with approval recording, a reviewer can complete acceptance through the interactive workflow above.

Publish after merge

After the reviewed change merges, a trusted publication job runs the existing privacy check and sends the accepted map to Noru only if it passes. Use the CI/CD publication workflow for that step.

Proposal generation does not require a Noru publication credential. The bot prepares changes; the existing check validates accepted files; the publisher sends them to Noru. These responsibilities can remain separate pipeline jobs.

Review the result in Noru

Open Privacy›Data map›Sources to inspect the source and its changes. Confirm legal basis, retention, and other legal decisions in Records of processing. Accepting or publishing a code-side map does not approve those decisions.

Related

• Bring your privacy data into Noru
• Data map
• Connect an MCP client