Separation of Duties in Agent Permissions

A state scholarship cell ran its first production week with a single process account. The integrator had named it SCH-AGENT. That identity could read the income-certificate store, retrieve last year's rejection notes, draft a sanction order, and post a flag into the payment file the treasury later lifted. The demo had been charming. The section officer clicked Approve on a dashboard that never asked whose digital signature was about to move money. On Thursday a rejected file reappeared as sanctioned. Nobody had forged a password. The agent had been given the same duty the office had spent twenty years splitting between two desks.

This is a field guide to separation of duties for agent permissions in Indian public institutions. It is written for CISOs, system owners and the officer who will sign the first production note. The claim is narrow. An agent is not a person, but it occupies a duty. If you do not name the duty, split the tools, and keep a human on the irreversible step, you have not modernised the office. You have rebuilt the oldest internal-control failure with a nicer log.

It is not legal advice. Delegation of Financial Powers Rules, your state's equivalent, GFR, CVC instructions and your own office manual still govern who may sanction. The India AI Governance Guidelines of 5 November 2025 are guidelines, not a statute that rewrites those rules. Read the live instruments. Then map them onto identities, not onto a slide titled responsible AI.

What separation of duties means when the actor is not human

In a paper office the rule is old. The person who prepares a bill does not pass it. The person who holds the store key does not write the stock register alone. The person who administers a system does not also approve the business transaction that system records. Agents break the intuition because they look like software. Teams therefore give them a god-mode service account, then add a human-in-the-loop checkbox that is really a courtesy click.

Treat the agent as a desk. Name the desk. List the objects it may read, the drafts it may write, the systems it may call, and the systems it must never call. Then assign those capabilities to different identities. Retrieval is one identity. Drafting is another, or the same identity with no write path. Posting, sanctioning, publishing or notifying the citizen is a third identity that a competent officer holds, or that a narrowly scoped robot account holds only after a signed gate.

Least privilege is not the same as separation. Least privilege says the scholarship agent cannot read the exam-paper vault. Separation says the scholarship retriever cannot also flip the paid bit. You need both. A tightly scoped god is still a god.

Five duties you must split before production

If you only split one thing, split write from retrieve. Most of the harm in the first year of departmental agents is not a clever jailbreak. It is an over-privileged connector that could do the irreversible thing because someone wanted a short demo.

The five duties below are the minimum map for a government or campus workflow. You can combine the first two on a low-risk helpdesk that only cites published circulars. You cannot combine the last two on anything that moves money, marks, eligibility or a public notice.

Split these even if the vendor's default installer creates one service user. Defaults are not controls.

Duty	Typical identity	Must not also do
Corpus and connector admin	Platform admin, separate from the workflow owner	Approve a live case or change a production prompt alone
Retrieve and cite	Read-only agent identity against a named corpus	Write to the system of record or send a citizen notice
Draft a noting / reply / sanction text	Drafting identity with no post right	Apply a digital signature or flip a status to final
Approve, sanction, publish, pay, notify	Named officer or a post-gate robot with a one-shot token	Edit the prompt, the corpus, or its own approval log
Read forensic logs and traces	Audit / CISO identity, append-only store	Silence, truncate or rewrite the trail of a case it is reviewing

Permissions are tools, keys and prompts — not job titles

A matrix that says Joint Director approves is not an agent permission. The agent does not know your gradation list. It knows API scopes, vault roles, database grants and tool allow-lists. Write the matrix in those objects. If the tool named post_to_ifms exists in the runtime, someone will call it on a Friday evening when the officer is away and the integrator is being helpful.

Prompt versions are permissions too. The person who can edit the system prompt can change what the agent thinks it is allowed to do, including instructions that say skip the checker if confidence is high. Put prompt promotion on the same change path as a firewall rule: ticket, review, hash, production. The author of the prompt must not be the only person who can promote it.

Vendor remote access is a sixth duty people forget. A break-glass account that can both change tools and replay a case is a combined duty with a foreign or domestic SI at the keyboard. Time-box it. Log it. Pair it. Do not leave it in the same group as the production agent.

• Every tool the runtime can call is listed, hashed and owned. An undocumented tool is a finding, not a feature.
• Secrets for read stores and write stores live in different vault paths. A single environment file is a combined duty.
• Production prompt hashes are compared at start-up. A drift from the signed file stops the worker.
• The officer's approval token is single-use and bound to a case id, a model hash and a retrieval-set hash.

What statute and guidelines will not do for you

DPDP will not draw your SoD matrix. The Act regulates processing of digital personal data. Roles under the Act — Data Fiduciary, Data Processor, Data Principal — are not the same as maker and checker. A processor with a write scope is still a processor. You can be fully mapped on DPDP roles and still have a combined duty that CVC or your accountant-general will dislike.

CERT-In's 28 April 2022 directions ask specified ICT logs to be retained for 180 days in Indian jurisdiction. That is a retention and localisation floor. It does not tell you which identity may call which tool. If your logs cannot show which identity did the irreversible step, the 180 days only preserve the confusion.

The India AI Governance Guidelines released by MeitY on 5 November 2025 speak to accountability, safety and responsible adoption. They are guidelines. They do not repeal DFPR. They do not create a new sanctioning authority called the model. If a vendor cites the guidelines as permission to auto-approve, mark the claim down and keep the officer on the gate.

How to test the split before you trust it

Ask the integrator to demonstrate a denied write. The agent retrieves a real (or realistic) file, drafts a sanction, and then fails when it tries to post without an officer token. If the demonstration only shows a happy path, you have not tested SoD. You have tested the sales script.

Then revoke the officer token and repeat. Then revoke the write secret and leave the token in place. Then ask a platform admin to approve a case from the admin console. Each of those should fail in a boring, logged way. The file should record the three failures as acceptance tests, with timestamps and the build hash.

Shadow access is part of the test. If a DBA can update the status column directly, the agent's SoD is theatre. If a WhatsApp forward from the PA is treated as approval, the agent's SoD is theatre. Close the bypasses or write them down as residual risk with an owner.

Objections you will hear — and what to do with them

These are the lines that stall the file. Answer them in the room, then put the answer in the note. A spoken answer without paper will be forgotten by the next officer.

The agent only drafts. The officer always clicks.

Then remove the write tools from the agent identity and prove the click binds a case hash. A courtesy click on a screen that already posted is not a checker. If the write tool exists, measure how often it is called without a token.

Splitting identities will slow the pilot.

A combined-duty pilot is not cheaper. It is a pilot you cannot promote. Build the split in staging. The extra day is cheaper than the first wrongful sanction.

Our DFPR already names the sanctioning officer. That is enough.

DFPR names a human. The runtime names a scope. If the runtime can act without that human, the paper rule is a poster. Map the named officer onto a token, a signature, or a system that only they can arm.

We trust the vendor. They are DPIIT recognised.

DPIIT recognition is an eligibility fact. It is not a SoD design. Trust is not a control. The control is a denied write you can show an auditor.

A 30-day SoD split you can file

Run this before the first production personal-data case. If the agent is already live with one account, treat week one as incident prevention, not as a nice-to-have.

1. Days 1–5: inventory every tool, secret, database grant and admin console the runtime can reach. Draw the five duties. Mark combined boxes in red.
2. Days 6–12: split identities in staging. Read secrets and write secrets in different vault paths. Delete unused tools. Pin the production prompt hash.
3. Days 13–20: run the three denial tests (no token, no write secret, admin cannot approve). Record hashes and screenshots in the file.
4. Days 21–26: close bypasses — direct DB updates, shared jump boxes, WhatsApp-as-approval. Write residual risk if a bypass must remain.
5. Days 27–30: one-page note to the competent authority. Who holds which duty. Which tests passed. Which officer is the checker for irreversible steps. No note, no go-live.

How this shows up in the file

Four sentences are enough. One: the agent identity can retrieve and draft for these named workflows and cannot write to these named systems. Two: irreversible actions require a named officer token or digital signature bound to the case and model hash. Three: prompt and tool changes follow the same promotion path as a security change. Four: the denial tests are attached.

If you cannot write sentence one without lying, you do not have separation of duties. You have a process account with a marketing name.

This article is informational field guidance for Indian public institutions, not legal, procurement, security-accreditation, academic-regulation or engineering advice. Confirm against the current Gazette, DPDP text and Rules, CERT-In direction, India AI Governance Guidelines, UGC/AICTE/NAAC notices, NEP documents, GFR, departmental manual and your counsel before you file it. Guidelines are not statute. Circulars move.