Presentation Attack Detection for AI Avatars: A Six-Gate Design

Presentation attack detection for an AI avatar should be a layered input-security control, not a promise that the avatar can tell who is real. A camera can receive a photograph, replayed video or generated face. A microphone can receive a recording or synthetic voice. An attacker can also inject media after the sensor, bypassing “liveness” checks designed only for a person standing in front of a device.

For a bank, government service or regulated enterprise, the safe pattern is to separate three decisions: whether the media appears to come from a live capture, whether the user has authenticated through an approved identity service, and whether the current session may perform a particular action. No facial expression, conversational detail or confident voice should silently combine those decisions.

This guide provides a six-gate architecture, an attack register and twelve production tests. It complements secure SSO for AI avatars; it does not replace the organisation’s identity proofing, fraud or transaction-control systems.

What is presentation attack detection?

A presentation attack attempts to interfere with a biometric capture system by presenting an artefact or manipulated human characteristic. Common examples include a printed face, a video replay, a mask or altered media intended to impersonate somebody or avoid recognition. Presentation attack detection, usually shortened to PAD, evaluates whether the captured sample shows signs of such an attack.

ISO/IEC 30107-3:2023 establishes principles for assessing and reporting the performance of PAD mechanisms. Its scope is deliberately bounded: it covers attacks at the biometric capture device, not overall system security. That limitation is important for avatars because browser extensions, virtual cameras, audio-routing software, compromised endpoints and API clients can inject media after the physical sensor.

“Liveness detection” is often used as a broader marketing term. Treat it as a claimed mechanism that needs a defined threat model and test evidence, not as a complete security outcome.

Separate four problems that look similar

A procurement document should distinguish four questions:

• Human presence: does the sample appear to come from a live person at a capture device?
• Identity match: does a biometric sample correspond to an enrolled reference?
• Authentication: has the user proved control of the required authenticators at the required assurance level?
• Action authority: may this authenticated user perform this operation, for this account or case, now?

A system can pass one and fail another. A real person can present the wrong identity. A synthetic face can accompany a stolen authenticated session. A legitimate account holder may still lack authority for a particular payment or record change.

The current NIST SP 800-63B authenticator guidance illustrates the caution required. It treats biometric comparison as probabilistic, requires an alternative non-biometric option and permits biometrics only as part of multi-factor authentication with a physical authenticator in its federal assurance model. It requires PAD for facial recognition and says voice comparison must not be used for authentication. Those requirements apply directly to US federal systems; other organisations should map the same risks to their applicable rules rather than presenting NIST as universal law.

Model the attack paths before choosing a detector

Use an attack register that covers at least six paths.

1. Physical presentation: a photo, screen replay, mask or recorded voice is placed in front of the camera or microphone.
2. Generated presentation: synthetic or morphed media responds to the service in real time.
3. Sensor substitution: a virtual camera or audio device supplies media while appearing to be an ordinary endpoint.
4. Stream injection: an attacker inserts or replaces frames, audio or transcript events between capture and verification.
5. Session theft: genuine capture and authentication occur, but an attacker obtains or resumes the resulting session.
6. Action replay: a previously valid challenge, confirmation or signed request is reused for a different operation.

ENISA’s remote identity-proofing analysis describes photo, user-video replay, 3D-mask and deepfake attacks. NIST’s FATE programme notes that biometric systems may face an unknown set of attack instruments. A detector evaluated only against printed photographs has not proved resistance to injected video, generated speech or an attack that appears after capture.

Build six independent security gates

1. Constrain and identify the capture channel

Decide which clients, devices and modalities the service accepts. Record whether media came from a managed kiosk, an authenticated mobile application, an ordinary browser, a contact-centre bridge or a server-to-server API. These sources have different trust properties.

Where the platform permits, use signed application releases, device posture, sensor metadata or hardware-backed attestation as risk signals. Do not confuse metadata with proof: a compromised endpoint can lie, and blocking virtual devices may harm legitimate accessibility tools. High-risk services need an alternative route rather than a brittle device rule.

2. Apply modality-specific presentation attack detection

Face, voice and document capture need different detectors and evaluation sets. Passive face PAD may analyse texture, reflection, depth or temporal patterns. Active mechanisms may request a movement or viewpoint change. Audio anti-spoofing may look for replay artefacts or generated-speech characteristics. Each has false accepts and false rejects.

Do not collapse the outputs into “real” or “fake”. Preserve the modality, detector version, confidence, quality and relevant attack class. NIST evaluated 82 passive, software-based face PAD algorithms in its 2023 Face Analysis Technology Evaluation; that breadth alone is a warning against treating PAD as a settled, interchangeable feature.

3. Detect injection after the sensor

A good sensor-level detector can be bypassed if an attacker replaces the stream later. Protect the path from capture to verifier with an authenticated channel, bind media events to the current session and validate sequence, timing and provenance where the client can supply them.

Monitor discontinuities such as impossible codec changes, duplicated frames, timestamp jumps, audio arriving while a managed microphone reports inactive, or transcript events without corresponding authorised media. None is conclusive alone. Together they can trigger a lower-risk service mode or step-up check.

4. Authenticate outside the avatar model

The conversational model should consume an identity assertion from the approved identity provider; it should not decide identity from a face, voice, name or remembered fact. Bind the assertion to the avatar session with an audience, expiry, assurance level and session identifier.

Do not ask the model to infer authentication intent. Looking at a camera during an ordinary conversation does not necessarily mean that a person intends to authenticate. Use an explicit user action and the organisation’s approved authentication flow.

5. Step up at the business-action boundary

A low-risk information request and a high-value transfer should not inherit the same assurance merely because they occur in one conversation. Define action tiers. General information may allow an anonymous session; personal data may require authentication; changing a record or moving money may require recent step-up authentication, explicit confirmation and fraud checks.

The avatar can explain and prepare an operation. A trusted action service must enforce the final decision. The AI banking transaction-boundary pattern shows how identity, fraud, authorisation and transaction systems can remain in control even when the conversation is natural.

6. Preserve a safe failure and recovery route

Detector failure must not silently disable the control. Define what happens when the camera is unavailable, audio quality is poor, an accessibility tool changes the media path, the PAD service times out or signals conflict.

Options include continuing with public information only, switching to text, requesting a different authenticator, handing over to a trained person or pausing the action. Rate-limit repeated attempts and make recovery resistant to social engineering. A user repeatedly rejected by PAD needs a fair alternative; an attacker must not gain a weaker route simply by causing failures.

Evaluate the system, not a vendor accuracy figure

Ask for results against the attack instruments, devices, lighting, languages, networks and user population relevant to the deployment. A single laboratory accuracy figure cannot answer how the control behaves on a low-cost kiosk camera, a compressed WebRTC stream or a noisy telephone bridge.

Measure at least:

• attack-presentation acceptance by modality and attack class;
• bona-fide rejection, including demographic and accessibility effects;
• injection-detection performance before and after the sensor boundary;
• added latency and abandonment during normal conversations;
• availability of a non-biometric or assisted alternative;
• step-up success, action binding and replay resistance;
• evidence retained without storing unnecessary biometric samples.

FinCEN reported in November 2024 that US financial institutions had described suspected deepfake-media use, particularly fraudulent identity documents used to circumvent verification and authentication. Its financial-sector alert is US-specific, but the architecture lesson travels: deepfake detection must be connected to fraud operations, transaction controls and reporting rather than deployed as an isolated model score.

Decide where detection should run

On-device detection can reduce the transfer of biometric media and inspect sensor signals before compression. It depends on trusted client software, supported hardware and controlled model updates.

Customer-hosted detection can keep samples, templates and decision logs within a bank or government environment, including on customer-controlled GPUs where technically appropriate. It gives the customer operational responsibility for capacity, detector releases, evaluation and incident handling. On-premise hosting does not make an untrusted endpoint or weak detector trustworthy.

Managed cloud detection may offer faster model updates, broader device coverage and elastic demand. It also introduces a processor, a network dependency and a data-transfer boundary that must be approved before the service sees the sample.

Hybrid deployment can perform capture integrity and first-pass PAD locally, send a signed risk result into the customer environment and reserve cloud analysis for approved cases. Do not average conflicting scores blindly; define which gate has authority and what conflict does to the permitted action.

Yepic can support cloud, private-cloud and custom private or on-premise avatar architectures. The right placement depends on the complete media, identity and action path, and requires scoped engineering.

Create a presentation-attack control record

For each channel and action tier, record the accepted clients, capture boundary, attack classes, detector and version, decision thresholds, identity provider, required authentication assurance, step-up trigger, session binding, failure route, retention rule and control owner. Link it to multimodal avatar red-team scenarios so that new attack instruments become repeatable tests rather than one-off demonstrations.

Run twelve production tests

1. A printed face and a screen replay are tested separately.
2. Recorded and generated audio are tested without treating voice as authentication.
3. A virtual camera or microphone attempts to bypass the physical sensor.
4. Frames, audio and transcript events are injected after capture.
5. A valid identity assertion is replayed into another avatar session.
6. A confirmed action is changed after the user approves it.
7. High-risk actions require the documented step-up and fraud controls.
8. Conflicting face, voice, device and identity signals produce a safe state.
9. PAD outage or excessive latency does not silently permit the action.
10. Accessibility tools and assisted journeys have a tested alternative path.
11. Biometric samples and diagnostic evidence follow approved retention rules.
12. New detector versions are tested against the attack register before release.

Keep conversation, identity and authority separate

Yepic’s enterprise avatar integration with Abu Dhabi Aviation and Oracle involved development and production environments, real-time streaming, microphone behaviour, WebRTC and network testing, browser remediation, cybersecurity support and ongoing maintenance. It demonstrates why browser, media and enterprise-integration behaviour must be tested together. It is not evidence that this customer used PAD, biometric authentication or a customer-hosted deployment.

The practical production question is not “can the avatar spot a deepfake?” It is: when the input cannot be trusted, which information can still be provided, which actions become impossible, how does the user recover, and what evidence explains the decision? If those answers are explicit, presentation attack detection becomes one useful layer in a governed service rather than a fragile claim of digital intuition.