Security & Threats
Authentication Design for Agent Access
· 10 minute read
Three doors: the citizen, the officer, the machine. Separate issuers, short tokens, no borrowed SSO, no shared ai-prod password.
The architecture slide said SSO. The implementation was a long-lived token in an environment variable on the planner host, minted from a developer account that had left in March. Authentication had been a checkbox. The box was ticked. The door was a corridor.
Agent estates have three subjects. A citizen proving they may see their own case. An officer proving they may see a queue. A machine proving it may call a tool. If you collapse those into one secret, you have built a master key and called it modern.
This guide is for CISOs on 17 August 2026. Not legal advice. It will not pick your identity provider. It will insist that captcha is not authentication, that a system prompt is not authentication, and that a vendor console login is not your officer's login.
Prcept will not run tools under a departed developer's token. If that is the current state, we start there, not with a model demo.
Door one — the citizen
If the desk can see personal data, the citizen authenticates with the same assurance you already use for that class — OTP, Aadhaar-linked where lawful and chosen, campus SSO, whatever the parent portal uses. Do not invent a weaker side door because the chat UI felt informal.
Session binding: the retrieval ACL uses the authenticated identifier, not a name the user typed. Names are not authenticators.
Public, non-personal FAQ can stay unauthenticated. Then it must not be able to pivot into personal collections. That pivot is an auth bug, not a model bug.
Door two — the officer
Officers use official SSO with MFA. No personal Gmail. No shared cell phone as the second factor for a whole section.
Step-up when they publish. Reading a draft and signing a speaking order are different assurances. The click that moves a right should hurt a little.
Break-glass is a separate identity, not the daily one. Logged, short, dual.
Door three — the machine
Workload identity: a client credential or a signed assertion from an issuer you own, bound to one verb set, short lived, rotatable. Not a password in a ticket. Not the officer's refresh token cached 'for convenience'.
The planner presents the machine identity to the connector. The connector does not trust the model. The connector trusts the issuer.
Vendor access to operate the node is yet another identity, time-bound, not the machine identity of the agent. Operators are insiders. They do not get to be the agent.
| Subject | Authenticator | Never |
|---|---|---|
| Citizen (personal) | Portal SSO / lawful OTP at the parent assurance | Typed name, captcha-only |
| Citizen (public FAQ) | None, if no pivot | Hidden personal retrieval |
| Officer | Official SSO + MFA, step-up to publish | Personal mail, shared inbox |
| Agent tool | Short-lived machine credential | Borrowed human token, env password |
| Vendor operator | Named, time-bound, logged | The agent's client secret |
Tokens are secrets with a clock
Long-lived tokens are standing admin. Rotate. Bound them to audience and verb. Log presentation, not the token value, into the 180-day store.
Revoke must work when an officer leaves and when you believe a planner host is dirty. If revoke needs the vendor's business hours, you do not have authentication. You have a subscription.
Do not put tokens in prompts, traces, or eval sets. The secrets article is the handling guide. This page is the door design.
- Three subjects, three issuers or three clearly separated credential classes.
- No departed humans in the grant list.
- No pivot from public to personal without a new authn.
- No tool call on a citizen session using an officer grant.
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.
SSO is hard on a gapped estate.
Then run a local issuer or a one-way sync you understand. Hard is not a reason to share a password called ai-prod. Gaps do not excuse master keys.
The model can recognise regular officers by style.
No. Style is not a factor. That sentence should never appear in a file.
API keys are fine if they are long.
Length without rotation, audience lock and revoke is just a long master key. Prefer short-lived assertions.
Citizens will not complete MFA for a chatbot.
Then the chatbot does not see personal data. Convenience is how you choose the unit, not how you weaken the parent portal.
A twelve-day door review
Draw three doors. If you cannot, you do not have a design.
- Day 1–2: inventory every credential on the estate, including forgotten env files.
- Day 3–4: map each to a subject. Kill hybrids.
- Day 5–6: bind retrieval ACL to the authenticated identifier. Prove no pivot.
- Day 7–8: put machine credentials on a short TTL. Test revoke.
- Day 9–10: step-up on publish. Remove shared officer inboxes from the path.
- Day 11–12: leaver drill on a departed vendor. CISO signs the door diagram.
How this shows up in the file
Subject: Authentication design — agent [name].
Citizen door: [issuer, assurance, no pivot]. Officer door: [SSO, MFA, step-up]. Machine door: [issuer, TTL, audience]. Vendor operators: named, not the machine identity. Departed identities: none on the grant list as of [date]. Revoke tested [date], [n] minutes. Tokens never in prompts. Not legal advice.
A slide that says SSO is not this note.
Ghosts on the grant list
Dump machine identities monthly. Last-used date. Owner. Audience. If a token has not been used and the owner has left, rotate it as if it were stolen. Ghosts are how March becomes August.
Vendor operators must not share the agent's client secret. Their access is named, time-bound, and logged. When the face on the SI ticket changes, the old face dies the same day. Processors are companies. Insiders are faces.
On a gapped estate, build a local issuer or a one-way sync you understand. Hard is not a reason for ai-prod. A local issuer with short TTLs is lighter than a master key that outlives every contractor.
This article is informational field guidance for Indian public institutions, not legal, procurement, security-accreditation or engineering advice. Confirm against the current Gazette, GFR, GeM term, CVC instruction, CERT-In direction, DPDP text, departmental manual and your counsel before you file it.
How to fail this before citizens do
“Authentication Design for Agent Access” is a path problem. A P4 Security/CISO should be able to name the tool, the identity, the secret and the egress that would make “agent authentication design” real. If the only control is a network diagram from last year, you have a story, not a threat model.
Three doors: the citizen, the officer, the machine. Separate issuers, short tokens, no borrowed SSO, no shared ai-prod password. Air-gap is not automatically secure. Prompt injection is not a conference joke when the agent can write a ticket. CERT-In still wants specified logs in India and incidents on a six-hour clock. Write those clocks into the runbook.
- Red-team the write tools, not only the chat UI.
- Kill undeclared outbound paths on staging.
- Redact personal data from logs you will actually keep.
- Scope a pentest that includes RAG and connectors.
- Cap metered spend so a loop cannot empty a budget.
Close this loop before the next CAB
Put “Authentication Design for Agent Access” on the next change-advisory or bid-opening agenda as a single line item with an owner. If it cannot earn a line item, it will not earn a control. The owner should be a P4 Security/CISO, not “the vendor.”
Revisit the item when the model, the GeM term, the region, or the SI changes. “agent authentication design” is not a one-time workshop. It is a watch item. Date the last check. Unsigned watch items are souvenirs.
What must be true before you file this
If “Authentication Design for Agent Access” is only a heading, it will not survive a file inspection. A P4 Security/CISO should be able to attach one artefact that proves “agent authentication design”: a log export, a clause, a scored row, a dated notice, or a refusal rule.
Write three dated sentences: what was decided, who owns it, and when it will be re-checked. Unsigned sentences are souvenirs. Dated sentences are controls.
- Name the owner of “agent authentication design” inside the institution.
- Attach one artefact a stranger can open next year.
- Revisit when the model, the notice, or the SI changes.
- Do not treat a vendor slide as evidence.
What the next file must contain
“Authentication Design for Agent Access” earns a line in the noting only if a P4 Security/CISO can attach proof of “agent authentication design.” A heading is not proof. A vendor slide is not proof. A workshop photograph is not proof.
Write three dated sentences: what was decided, who owns it after the next posting order, and when it will be re-checked. If you cannot write the three sentences, you are not ready to buy, to sell, or to go live.
Leave unsourced percentages out of the note. DPDP is not a blanket localisation statute. The November 2025 AI governance text is guidance, not an Act. CERT-In’s 28 April 2022 directions still set specified incident and log clocks. A PAC, when lawful, lives in GFR Rule 166.
- Name the designation that owns “agent authentication design.”
- Attach one artefact a stranger can open next year.
- Record the instrument you are actually using.
- Revisit when the model, the SI, the notice or the posting changes.
Questions this usually raises
- Is captcha authentication?
- No. It is a bot speed-bump. It does not identify a principal. Put that in the file next to “agent authentication design” so a stranger can reconstruct it. A one-line yes/no under “Authentication Design for Agent Access” is not an answer a secretary can defend. Confirm against the live Gazette, circular or GeM term; this is not legal advice.
- Can the agent use OAuth on behalf of the officer?
- Only with a constrained, user-present grant that cannot be replayed by the planner later. Cached 'on behalf of' is a borrowed human. Prefer the officer clicking in the system of record.
- What about service accounts in Active Directory?
- They can work if they are unique, non-interactive, tightly grouped, and monitored. A shared svc-ai in Domain Admins is a museum piece. Retire it.
- Does DPDP specify authenticators?
- No. It expects reasonable security. Match the parent portal's assurance for the same data class.
- How short is a short-lived token?
- Minutes to a few hours, with refresh that can be killed. Days is standing. Months is a scandal.
- Will Prcept bring its own IdP?
- We will plug into yours or help you stand a local issuer on a gap. We will not hide a master key in our installer.
Sources
- ISO/IEC 27001 — Information security management
- CERT-In Directions under Section 70B, 28 April 2022 (PDF)
- Digital Personal Data Protection Act, 2023 (India Code)
- Prcept AI — on-prem / air-gapped agents
- OWASP Top 10 for Large Language Model Applications
- India AI Governance Guidelines (PIB document, November 2025)