Connect the agent to read results and request checks within set limits. It should never be able to override a verification outcome, change match thresholds or see raw biometric data. Run it under its own identity, hold any second attempt or manual review request for a person, and log every call so each check can be traced.
What kind of service is this, and who owns the connection?
An identity verification service checks that a person is who they claim to be. Depending on the provider, it compares a document to a selfie, checks a document's security features, matches data against reference sources, or confirms control of a phone or bank account. It returns a result, a score and usually the reasons, and it charges per check.
The KYC or fraud operations lead usually owns the service; information security and data protection must approve any new integration, because the service processes identity documents and often biometric data. The connection matters in customer service as much as in onboarding: agents that talk to customers need identity assurance before they act, as the identity verification script template for support agents sets out.
What are the steps to connect it?
- Person, service owner: creates a dedicated API identity for the agent. Separate from the onboarding application's key, with its own rate limit and spend limit.
- Person, KYC lead and data protection: define the capabilities. Usually: read the result and reasons for a check; request a new check for an existing customer; resend a verification link. Each is a separate scope.
- Person, compliance: sets the depth each action needs. Reading results at depth 1. Requesting a first check within defined triggers at depth 3. Any repeat check after a failure, and any request for manual review by the provider, held for a person. Overriding a result, editing thresholds or deleting checks is outside the agent's role.
- Person, data protection: minimises what the agent receives. The outcome, the reason codes and the matched fields. Not the document image, not the selfie, not the biometric template.
- Agent, depth 1: runs against test identities provided by the service, including failures and edge cases.
- Person, service owner: confirms revocation by disabling the key and checking the next call fails.
- Person, KYC lead: approves go-live.
| Capability | The agent does | Depth | Stays with a person |
|---|---|---|---|
| Read result | Reads outcome and reason codes | 1 | None |
| Request first check | Sends a request on an approved trigger | 3 | Defining the triggers |
| Repeat after failure | Proposes, held | 2 | Deciding to try again |
| Manual review | Proposes, held | 2 | Requesting it |
| Override result | Nothing | None | Not available to the agent |
| Change thresholds | Nothing | None | Service owner, under change control |
Which controls apply, and what evidence does each leave?
Spend and rate limits on the agent's key. A loop or an attack that triggers thousands of checks is a cost and a nuisance to customers. Evidence: the configured limits and any breaches of them.
Triggers defined, not inferred. The agent may request a check only for listed reasons, such as a change of contact details or a high-value request in a support conversation. A check requested for any other reason is refused. Evidence: each request names its trigger.
Results stored as signed facts. A result from the service comes from a named party that answers for it, which is a stronger basis than a customer's own statement. The agent should treat a customer saying "I already verified" as declared and check the record. Evidence: each result carries its source and time.
Failures go to people. A failed check can mean fraud, or a poor photo, or a customer with an unusual document. Deciding which is not the agent's job. Evidence: every failure has a named reviewer.
Data minimised at the connection. If the agent never receives images, it cannot leak them. Evidence: the integration specification, showing which fields are returned.
What should you measure?
- Checks requested per trigger, to spot drift or abuse.
- Spend against budget for the agent's key.
- Failures and their resolution, including how many were fraud.
- Calls refused by scope, which should be few.
- Customer drop-off after a check request in support channels.
Where does it usually go wrong?
Re-running until it passes. If the agent may retry freely, a fraudster can keep submitting until a check succeeds. Repeat checks after a failure must be held.
The agent treated as the verifier. The service verifies; the agent orchestrates. Do not let a model's view of a photo stand in for the service's result.
Ownership checks forgotten for businesses. Verifying a director's identity does not establish who owns the company; see the beneficial ownership verification checklist.
Consumer protection ignored. Asking a customer to verify mid-conversation can feel like a barrier. In the UK, the expectations in FCA Consumer Duty and AI agents in customer service apply; in the US, see the CFPB on AI chatbots and agents.
The work that follows the connection is covered in letting an agent request identity checks on customers, and the broader stance in AI compliance agents.
Where Pryme fits
In Pryme, results from the verification service arrive through the Pryme Context Protocol as signed facts, with the provider named, while anything the customer states stays declared. The agent is certified on the customer's own cases before its requests run at depth 3, and the certificate lapses after 90 days. Overrides are outside the agent's role scope, so an attempt is refused and filed.
Questions people ask
Does the agent need to see the identity document?
Usually not. The outcome and reason codes are enough to route the case. Where a person needs the image, they view it in the service's own console.
Can one key serve several agents?
It should not. Each agent should have its own identity so that limits, logs and revocation apply to one agent at a time.
What if the service is unavailable?
The agent should hold the action that needed verification and tell the customer plainly, not proceed without it. Define the fallback in advance with the service owner.