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

A CI bot would automate the preparation work you otherwise request in a chat. It could run as a pipeline job when code changes; a separately deployed service would be optional. The bot would investigate changes and prepare a reviewable proposal, while a person remains accountable for accepting privacy decisions.

Configure the runner

The runner would need the application checkout, the plugin's instructions and tools, and a configured model provider and model. An OpenAI or Anthropic API key could power the analysis, stored in the CI secret store and supplied only to the agent job. Provider support and configuration would depend on the runner implementation; no additional plugin environment variables are defined here.

The runner would also need repository integration to open or update a merge request (GitLab) or pull request (GitHub). A bot account or appropriately scoped repository credential would authorize those changes. If the integration cannot write proposals to the repository, it could 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

The proposed GitLab integration would use a trusted pipeline definition in .gitlab-ci.yml 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. Automatic merge request triggers could be added once the credential and execution boundaries are validated.
3. Produce the proposal. The runner would 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. That integration would still need to be implemented; it is not supplied by the plugin today.

GitHub Actions approach

The proposed GitHub integration would use a workflow under .github/workflows/ 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. The runner would 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 outlines require a runner and repository adapter to be built and tested. The provider keys power analysis; they do not install a GitLab or GitHub bot. The following acceptance and publication rules apply to both providers.

Prepare a proposal and obtain review

The proposed pipeline would:

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.

The integration would need to 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. Until an approval integration exists, 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

• Privacy ingestion methods
• Data map
• Connect an MCP client