Face verification used for authentication without presentation-attack detection

Run liveness detection before any face match used to authenticate, and return only the decision.

On every login, unlock or identity-verification route that compares faces, run presentation-attack detection first and reject on failure: a liveness service (AWS Rekognition create_face_liveness_session / get_face_liveness_session_results, Azure AI Face liveness sessions) or a local anti-spoofing model (DeepFace anti_spoofing=True, a FasNet-style detector), preferably one whose performance was tested with the methods of ISO/IEC 30107-3. Then match, and return only accept or reject with a reason code: no distance, similarity or confidence value to the client, and rate-limit attempts per account.

Where it goes: 1 application source code, 6 API calls and integrations, 9 AI output handling.

What reviewers look for: a liveness or anti-spoofing call on the same path before face_recognition.compare_faces, DeepFace.verify, Rekognition compare_faces or face-api matching in a login or verification function; responses from those routes that carry a boolean decision but no distance or score.

def login_with_face(user, frame):
    result = DeepFace.verify(frame, user.enrolled_face)
    return {'ok': result['verified'], 'distance': result['distance']}

def login_with_face(user, frame):
    try:
        result = DeepFace.verify(frame, user.enrolled_face, anti_spoofing=True)  # raises on a spoof
    except ValueError:
        return {'ok': False, 'reason': 'liveness_failed'}
    return {'ok': bool(result['verified'])}   # the decision, not the distance

Engineering guidance, not legal advice. Each provision below may add its own details (a cadence, a deadline, a required notice element): open it for those.