Who is the relying party, and what should it check?

A loan officer at a mid-sized bank gets an application. It arrived through the bank's service for partners, and it says it was submitted by an AI agent on behalf of a customer. The figures look sensible. The customer's number matches a real account.

The officer has two minutes before the next one. What should be checked before anything else happens?

Most desks today would check whether the customer is real. That's necessary and it isn't enough, because the thing talking to the bank isn't the customer. It's an agent, and the agent is a new kind of party in the room. The bank is the relying party here: the office that is about to rely on someone else's claim and act on it.

Six checks, in this order

The order isn't decoration. Each check makes the next one meaningful, and an early failure means you can stop.

First, is the agent's identity signed, and has it been switched off? Someone the bank can verify has vouched that this agent exists, and that vouching hasn't been withdrawn. If the answer is "unsigned" or "withdrawn last Tuesday", nothing after this matters.

Second, who answers for it? A named person or company, with a way to reach them. Not "the platform", and not a mailbox nobody reads.

Third, does its scope cover this exact action? Permission to look at an account is not permission to apply for a loan. The check is against what's being asked right now, for this task, and a general trust in the agent doesn't count.

Fourth, does the delegation chain narrow? The customer handed some authority to a company, which handed some to the agent, which may hand some to a helper. Each hop can pass on only part of what it received. If any link claims more than the one before it, the chain is broken.

Fifth, what is the data-protection status? The agent is about to handle a customer's personal data. Has whoever stands behind it said how it handles that, in a form the bank can look at? Under India's Digital Personal Data Protection Act 2023, the bank has its own duties here too. This isn't legal advice, and the bank's counsel should say what applies.

Sixth, is there evidence written before acting? The bank records what it saw and what it decided, before it processes the application, not after. If it only writes the record once the loan is approved, the record can quietly turn into a story about a decision.

The diagram shows where these checks sit in the life of an agent's permission. The checking is the step labelled Check. It happens every time, and it's the bank's own act.

Fail closed

If any check can't be completed, whether because a lookup timed out or because a document is missing, the answer is no. We call that failing closed.

It will annoy people. A request that would have been fine gets refused because a service was down. We think that's the correct trade for anything involving money, health or tax. For lower-stakes actions, an office could reasonably choose to queue the request for a human instead of refusing outright. What it shouldn't do is decide the default is "yes".

Leave the model score out

It's tempting to add a seventh check: a number that says how trustworthy the agent seems. Some systems produce one from the agent's writing style or its past behaviour.

We'd keep it out of the decision. A score is a guess made by a system the office doesn't control, and nobody can show it to a regulator and say "this is why we acted". It may help the agent's own operator find problems. It's not a substitute for any of the six facts above, and it shouldn't be able to outvote them.

Rolling it out without breaking things

No office can switch all of this on in a day, and trying to would just produce a pile of angry customers. We'd suggest three phases.

In the first, the office observes. It runs the checks on incoming agent requests and records the results, but acts as it did before. After a few weeks it knows what share of requests would have failed and why.

In the second, it warns. Failing requests still go through, but the officer sees a notice and the sender gets a message saying what was missing.

In the third, it enforces. Failing requests are refused, with a reason the sender can act on.

Skipping the first phase is the most common way to make the third one painful.

What we don't know

We don't know whether six is the right number. Some offices will say two of these belong together, and others will want a seventh for their own sector. We'd like to hear which.

We don't know how long the observing phase should last, or what share of failures an office will tolerate before it calls the checks too strict. That depends on the sector, and we have no figures.

We don't know how a small clinic with one receptionist can do any of this. The checks have to be cheap enough for a desk with no IT department, or only large offices will get them, and we haven't worked out how.

And we don't know what regulators will want kept as evidence, or for how long. Until they say, we'd keep more than less. We're setting up a non-profit to work on this, it isn't incorporated, and no regulator or company has endorsed the checks above.