Governing AI agent access to architecture data

The identity behind the request

An architect asks an assistant to list the dependencies of a claims application. The connection might use the architect’s authorization or a shared service account. Those two arrangements can expose different data and produce different audit records.

Record who owns the connection, why it exists, which architecture model it reaches and when the authorization expires. For a shared account, the team also needs a way to identify the person who initiated a request in the assistant.

Reading, proposing and executing

ArchiLU already provides MCP access and an agent authorization interface. Its modes include Read only, Propose and Auto-apply. These labels should be checked against the effective rights of the account and the server configuration used for the pilot.

Model changes pass through backend authorization and governance. A proposal can await a human decision; an authorized identity can execute changes within the applicable rules. Agent auto-apply requires the feature to be active, an appropriate authorization and guardrails on destructive operations, batch size and budget. A policy requiring approval takes precedence over that path.

An ADD has its own authoring operations. Creating or editing its content does not, by itself, realize the proposed architecture in the model. The project owner still needs a recorded decision on the proposed solution and its conditions.

A test with two identities

Use a normal project account and a more restricted account. Ask both for the same application, then attempt a change outside the intended authority. Record the returned objects, the refusal or approval status and the resulting model state.

Include relationships and summaries in the test. An object hidden from a direct lookup can still be revealed by a search result or a related object if the relevant control is missing. Test the operations the team intends to use, with representative data.

• Confirm that an allowed read returns the expected scope.
• Confirm that a forbidden operation is rejected by the server.
• Submit a permitted proposal and inspect its status before and after the authorized decision.
• Revoke the connection and check that a new request is refused.

The destination of retrieved content

A permitted read may send application names, suppliers or sensitive dependency information to the assistant’s model. The repository permission check does not choose the model’s processing region or retention policy.

The security review should follow the content from repository to MCP client, model service and any logs or caches. Identify the operators of those components, the configured regions and the retention terms. An EU-hosted repository alone cannot establish those facts for an external assistant.

For a first pilot, omit vulnerability details or personal data that the task does not need. If a filtering rule is required, test it where data leaves the repository or client. Check the content actually transmitted, even when the prompt already asks for sensitive data to be excluded.

Records for an investigation

For a proposed model change, retain the acting identity, target objects, change details, decision and execution result. For an ADD, retain the reviewed version and the people responsible for its decisions.

The assistant’s conversation history may contain additional prompts and tool results. Decide separately what must be retained there, who can read it and for how long. Copying every response into an unrestricted log would create another place containing sensitive architecture data.

The applicable regulatory assessment

For a financial entity within DORA’s scope, assess whether the arrangement is an ICT service from a third-party provider. Articles 28 and 30 cover the register of contractual arrangements and contractual provisions, with additional requirements for services supporting critical or important functions.

If personal data is processed, assess the GDPR basis, processor arrangements and any Chapter V transfer mechanism. Under the AI Act, classification depends on the system’s intended purpose and use. An architecture assistant’s interface alone does not determine its risk class.

The risk and legal teams should record the applicable provisions and the service arrangement they assessed. An internal connection policy can be stricter than a statutory minimum; identify which conditions come from that policy.

Access reviews tied to the work

Review the authorization when the pilot ends, the project changes owner or the assistant changes provider. Remove unused access and repeat the relevant tests after a material change in permissions or configuration.

The architecture lead owns the permitted use cases; the security team checks access and data handling; the project decision-maker accepts or rejects the proposed solution. Record the names and scope of those responsibilities in the project’s operating arrangements.

A review record with a decision

Close the trial with the actual data path, permission-test results, provider terms, reviewed ADD and unresolved issues. Each issue needs a responsible person and a due date. The authorized decision-maker can then approve the defined scope, restrict it or request a correction.

Repeat the affected checks when the model provider, client, permissions or data scope changes. A wider rollout should use the corrected pilot record as its starting point, including the limits discovered during the trial.