The anxious question people reach for when agentic AI and identity systems come up in the same sentence is usually some version of "what happens when an agent gets it wrong" — leaks something, impersonates someone, makes a call it shouldn't have made. It's an understandable question, and it's also the wrong one to start with, because it assumes the interesting failure has already happened by the time an agent is holding sensitive data at all. The question worth asking first is narrower, and far more tractable: can an agent ever put itself in a position to grant access to something that only a human was ever supposed to be able to grant?
That's not a philosophical question. It's an architecture question, and architecture questions have answers you can point to in code, not just promises you make in a policy document.
The conflation most systems make without noticing
Most access-control systems built before the agentic moment conflate two things that should never have been the same thing: the ability to request an action, and the ability to authorise it. If a caller — human or machine — can hit an API that both creates a request and fulfils it, then the distinction between "asking" and "getting" collapses into a single permission check, and the only thing standing between an agent and a sensitive grant is whether that one check happens to be configured correctly today.
That collapse is fine, mostly invisible, right up until the caller on the other end of the API is something that can be prompted, jailbroken, or simply given a badly-scoped task by someone who didn't think through what it could reach. A human operator with a poorly-configured permission is a known, bounded risk — one person, acting inside working hours, subject to a dozen social and procedural frictions that slow down misuse. An AI agent with the same poorly-configured permission is a different risk entirely, because none of those frictions apply to it, and it can act on the badly-scoped task at machine speed, repeatedly, without the pause a human would naturally take.
The regulatory backdrop isn't waiting for the industry to figure this out
India's Digital Personal Data Protection Act already sets the bar this has to clear regardless of who — or what — is doing the asking: purpose limitation, data minimisation, and consent that is specific, informed and revocable, not implied by the mere existence of an account or a relationship. None of that language carves out an exception for "unless the requester is an AI agent acting on a lender's behalf." A consent architecture that only holds up when the requester is a careful, well-supervised human is not a consent architecture that holds up at all — it's a set of good intentions that happened to work so far because most requesters, so far, have been human.
The industry conversation about agentic AI has moved fast — arguably faster than the governance thinking sitting underneath it, which is exactly the pattern that shows up whenever a new capability gets adopted before the access model around it has been properly worked through. Identity and consent is the one place in an evidence platform where getting that sequencing backwards isn't a minor product risk. It's the one family that, designed carelessly, would make every other capability an agent can reach untrustworthy by association — because if an agent could grant itself access to someone's identity data, no amount of careful scoping on the other four families would matter.
What "the agent can ask, only the holder can answer" actually means in the architecture
The fix isn't a policy that says agents shouldn't misuse consent. It's a structural separation between the two actions a "get someone's KYC verified" flow requires: creating the request, and approving it. An agent — a lender's own AI system, working through a queue — can create a consent-gated verification request. That's the "ask." What it cannot do, under any configuration, on any key, is complete the "answer" half. The request only ever resolves when the holder — the actual individual whose identity is in question — opens it on their own device and makes an explicit choice to approve or decline. There is no code path from "an agent created a request" to "a grant now exists" that skips that step. The human isn't a formality sitting next to the automation. It's the only thing that can authorise the automation's request at all.
What the agent gets back afterward is bounded the same deliberate way. Consent-bound personal data doesn't flow to an agent just because a grant exists — the default view an agent receives is status-only: is the grant active, expired, revoked, with a link back to the platform for a human to review the substance. If an organisation has explicitly opted in to a richer disclosure mode, an agent can see the specific fields the holder already chose to share when they consented — never more than that, and never a field the holder didn't already agree to disclose. That disclosure setting belongs to the organisation configuring its own workflow, not to the agent, and not to whoever happened to write the prompt that triggered the request.
Why this is the family that makes the other four trustworthy
Duplicate-financing checks, pre-credit signals, trade provenance, business identity — none of those four families involve a moment where an agent could grant itself something a human should have decided. This one does, structurally, by the nature of what KYC and consent are for. Getting the separation between "ask" and "answer" right here isn't just about protecting one family's data. It's the proof point that makes it credible to expose the other four to an agent at all — because an organisation evaluating whether to let its AI systems anywhere near an evidence platform is really asking one question underneath all the specific ones: if this system got the highest-stakes case right, on purpose, by design, not by policy — I can trust it got the others right too.
The right question was never "should an AI agent be allowed near identity and consent." It's narrower than that, and it has a concrete, checkable answer: can the architecture make it structurally impossible for an agent to complete a grant that only a human was supposed to complete? Build that correctly, and the anxious question about what happens when an agent gets it wrong stops being a question about trust, and becomes a question you can just go read the access-control code to answer.
Watch a holder consent on their own device, live, or read the consent model in full.