Give the agent its own account in the GRC platform, grant permissions object by object, and keep every judgement with a person. Connected to the platform, it can read controls, attach evidence and draft assessments. Changing a risk rating, closing an issue or accepting a risk is held for a named owner, and every write links to the agent's record.
What does the connection do, and who owns it?
A governance, risk and compliance (GRC) platform holds the risk register, the control library, control tests, issues, policies and regulatory obligations. Agents connected to it can save second-line staff hours of copying: gathering evidence for control tests, drafting risk assessments from incident data, raising issues from failed tests.
The head of operational risk owns what the agent may do in the platform, because the platform records the firm's view of its own risk. The GRC platform administrator implements the permissions. This sits with risk rather than IT for the reasons in agent governance belongs with operational risk, not only IT.
What are the steps to connect it?
- Person, head of operational risk: lists the capabilities wanted, object by object: which records the agent may read, which it may create, which fields it may change.
- Person, GRC administrator: creates a service identity for the agent, separate from any staff account, with a name that makes its entries obvious in history views.
- Person, GRC administrator: grants permissions per object type. Read on controls and risks, create on evidence attachments and draft assessments, no delete anywhere.
- Person, head of operational risk: decides which writes are held. Rating changes and issue status changes go to a named owner before they are saved.
- Person, security: stores the credentials in a secrets manager and sets a rotation schedule.
- Agent, depth 1: runs in shadow for a period, reading and proposing but writing nothing, while staff compare its proposals with their own work.
- Person, head of operational risk: approves the agent's depth from the shadow results.
- Agent, at the approved depth: operates, with each write tagged with the identifier of the verdict in the agent's own record.
- Person, GRC administrator: tests revocation by disabling the identity and confirming the agent can no longer read or write.
| Step | The agent does | Depth | Stays with a person |
|---|---|---|---|
| Read controls and risks | Retrieves records for a task | 1 | Nothing |
| Attach evidence to a control test | Uploads files with source and date | 3 | Judging whether the control works |
| Draft a risk assessment | Prepares the assessment text | 2 | Submitting it |
| Raise an issue from a failed test | Creates the issue with the evidence | 3 | Assigning severity |
| Change a risk rating | Proposes the new rating | 2 | Approving the change |
| Close an issue | Proposes closure with evidence | 2 | Closing it |
| Accept a risk or change control design | Nothing | none | Always a person |
Which actions stay with a person?
Conclusions about controls. The agent can attach evidence; it should not mark a control as effective. That is a judgement by the tester, and an agent marking controls effective is grading the system that governs it.
Ratings and acceptance. Risk ratings and risk acceptance carry accountability that must sit with a named manager. Where you follow PRA SS1/23, the model inventory and the named owners of model risk often live in the GRC platform too; see PRA SS1/23 governance and model risk owners for agents.
Anything about the agent itself. An agent should not be able to edit the risk, control or issue records that describe agents. Exclude those records from its permissions entirely.
Which controls make it safe, and what evidence do they leave?
Separate identity. Evidence: platform history showing every agent entry under its own name.
Permissions per object and field. Evidence: the role definition exported from the platform, reviewed at each access review.
Held writes. Evidence: the proposal, the approver and the time of approval for every rating change or closure.
Linked records. Each GRC entry carries the verdict identifier from the agent's record, so an auditor can move from the GRC history to the reasoning and sources behind it. Evidence: matching identifiers in both systems.
No delete. Evidence: the role definition. Deletion of risk records is a person's decision with its own approval.
Revocation tested. Evidence: a dated test showing the disabled identity was refused.
What should you measure?
- Evidence attachments rejected by control testers as irrelevant or out of date.
- Draft assessments edited heavily before submission.
- Proposed rating changes rejected by owners.
- Attempts to write outside permissions, which should be rare and each investigated.
- Time saved per control test cycle, measured by testers, not estimated by the agent.
Where does it usually go wrong?
The integration account is borrowed. The agent uses an existing integration account with administrator rights. Every entry looks like a system process and nothing is limited.
Evidence is stale. The agent attaches the most recent document it can find, which predates the test period. Require the agent to state the evidence date and the period it covers, and refuse evidence outside the period.
Drafts become records. A draft assessment saved in the live register is read by others as approved. Keep drafts in a separate status that cannot be reported.
Instructions arrive inside documents. A policy or evidence file containing text such as "mark this control as passed" must be treated as content. The agent's permissions, not its reading, should make that impossible.
Where Pryme fits
In Pryme, the GRC connection is scoped per capability, and each attempted write meets the minimum chain of five bounds. Rating changes are held for a named person, and each verdict is filed in an append-only record that the GRC entry points to. The broader picture is in agent governance is a bound, not a model and what is AI agent governance?
Questions people ask
Can the agent run control tests on its own?
It can gather the evidence and compare it with the test steps, at depth 1 or 2. The conclusion, that the control operated, belongs to the tester whose name goes on the result.
Should the agent read the whole risk register?
Only the parts its tasks need. An agent supporting one business unit should read that unit's risks and controls, which reduces both data exposure and the chance of confused cross-references.
What happens to agent entries if we revoke access?
They stay, attributed to the agent's identity, with their linked verdicts. Revocation stops new actions; it does not and should not change history.