A named person and duty
The person’s role and duties come from the Company Repo. They are built from the person’s own answers and confirmed by that person.
AI agent governance pilot · for security, identity and internal audit
Every AI agent has an owner.No agent has more access than its owner.
In a 30-day pilot on one division, we tie each AI agent to the person it works for and the tasks on that person’s cards. Rules check its access before anyone approves it. Your auditors get a record they can export.
Discuss a governance pilot See the agent manifest templateFor CISOs, identity architects, compliance and internal audit teams.
01 Human duty02 Task Card03 Agent design04 Approval record
The problem
Identity tools were built for people. AI agents act for people.
When a team adds an AI agent today, it often gets access by copying a service account or sharing a broad API key.
- Who answers for what the agent does?Often nobody is named.
- Why can it write to the ERP?Nobody wrote it down.
- Does it cross a segregation-of-duties line?Nobody checked.
Identity governance tools show who has access to which system. They do not show the work that justifies that access, or which person an agent acts for. DutyGraph starts from the work.
How it works
No agent permission without a person and a task behind it.
Each agent request goes through four steps, and each step is recorded.
The Task Card
It names the systems the task touches, what it reads and writes, and the point where a person must decide.
The agent design
We draft it from the Task Card for one named owner. Scopes that the cards do not list are removed before review.
The approval record
The manager, the system owner and internal controls approve in turn. Each decision goes on a hash-linked ledger that your auditors can export.
What you get
At the end of the 30 days.
An inventory of AI agents and their owners
Every proposed agent in the division, tied to one person, that person’s tasks and the systems the agent would touch.
Segregation-of-duties checks before approval
We load your rules and your conflicting duty pairs, such as creating a vendor and releasing a payment. A request that crosses a pair is flagged before anyone approves it.
Access checked against your identity data
We read an access export from your identity system, such as Okta, Entra or Saviynt, and compare each request with what its owner holds. In the pilot we read exports. We do not change access in your systems.
An audit packet
Every request, check and decision in order, with the version of each Task Card it relied on. Export it for internal or external audit.
What we build with you: live connections to your identity system, suspending an agent when its owner leaves, and approval of single high-risk actions while an agent runs. We scope these with your security team during the pilot. See what an enterprise evaluation covers.
The 30 days
One division. One workflow to start.
Pick a workflow where a mistake costs money or fails an audit.
- 01
Map the workflow and its access
Choose one sensitive workflow, such as procure-to-pay or vendor setup. The people who do it answer questions about their work, about 20 minutes each. We compare their duties with the access they hold.
Phase 1 · Days 1–10 - 02
Set the rules
Load your segregation-of-duties pairs and your approval chain. The owners confirm their Task Cards.
Phase 2 · Days 11–20 - 03
Approve the first agents
Run the first agent requests through the checks and the approvals. Internal audit gets the exported record, and we agree what comes next.
Phase 3 · Days 21–30
Next step
Start with one division.
Give your auditors a record they can check.
A short conversation to agree the workflow, the data we need and what success looks like.