Know Your Agent (KYA)
Definition. Know Your Agent is a defensive trust-policy concept for automated traffic. Where KYA is provisioned, a tenant can compare supported cryptographic agent identity claims with its own known, allowed, or denied entries.
The problem it solves is that an agent name or user-agent string is only a claim. Organizations need a stronger input before treating an automated client as known, while still defining safe behavior for clients that cannot present supported identity evidence.
KYA governs trust treatment at the traffic boundary. It does not grant an agent authorization inside your application, prove that an agent’s requested operation is safe, or enable the agent to act.
When it applies
Use KYA when your application receives automated traffic and needs to distinguish:
- a supported identity claim that verifies and matches tenant policy;
- a supported identity claim that verifies but is not yet known to the tenant;
- a denied identity; and
- traffic with absent, invalid, or unsupported identity evidence.
Your fallback for unknown traffic matters as much as the allow list. Observe or apply existing bot-risk policy until the identity and business purpose are understood.
How customers use it
For an eligible deployment:
- Inventory the automated agents that are expected to reach the protected domains.
- Record supported identity references and the tenant’s desired trust treatment.
- Define separate behavior for known, denied, and unknown claims.
- Observe matches and non-matches before introducing enforcement.
- Apply the result through customer-owned application logic or provisioned Browser Security controls.
- Review entries when an agent changes keys, signing authority, ownership, or business purpose.
The useful output is identity-verification and policy-match context associated with the request. Combine it with route sensitivity, device or browser risk, and normal application authorization.
How Noxtica does it
KYA uses public cryptographic identity references instead of trusting a display name:
- JWK thumbprints — stable references derived from public-key material can identify which key presented the claim.
- Signature-Agent hosts — the declared signing authority provides a host identity that can be checked as part of a supported verification path.
- Web Bot Auth verification — where supported, signed request evidence can be verified before tenant policy is evaluated.
These are public contract inputs. No single identifier establishes the agent’s intent, the human or organization behind every action, or permission to access an application resource.
Outputs and decisions
| Output state | What it means | Customer decision |
|---|---|---|
| Verified and allowed | Supported identity evidence matches an allowed tenant entry | Continue to normal application authorization; allow or observe by route |
| Verified and denied | Supported identity evidence matches a denied tenant entry | Apply the tenant’s approved deny or challenge policy |
| Verified but unknown | The claim verifies but has no matching trust entry | Observe, review ownership and purpose, then update policy deliberately |
| Invalid, absent, or unsupported | KYA cannot establish a supported identity match | Fall back to browser, device, network, and route policy |
An “allowed” result is not a bypass. The application still checks authentication, authorization, rate limits, and business rules.
What KYA is not
- It is not MCP. MCP lets your external agent read approved Noxtica context; KYA evaluates agents arriving as traffic.
- It is not the AI Assistant. The assistant helps an operator investigate tenant state.
- It is not proof of personhood, delegated business authority, or transaction approval.
- It does not identify every bot. Agents without a supported identity path remain unknown and require a fallback policy.
Eligibility and limitations
- KYA availability, supported identity standards, and managed enforcement depend on tenant provisioning and deployment context.
- Do not make KYA a launch dependency until the account team confirms eligibility and the intended agent identity path.
- Key rotation, authority changes, and malformed signatures can change verification status; maintain an operational review path.
- Browser and device scoring can complement KYA but cannot turn an unsupported identity claim into a verified one.
Where it fits
KYA is the incoming-agent part of the Intelligence pillar and the “police the agentic web” part of Agentic Security. It supplies trust context; Browser Security or customer code supplies the action.
Read deeper
- Agentic Security — the three agent workflows and their boundaries.
- Browser Security — how customer policy treats allowed, denied, and unknown traffic.
- Browser Intelligence — complementary browser and device evidence.
- Threat categories — the broader automated-traffic context.
- Features: agent identity and control — the customer-facing KYA capability family.
- Contact — confirm KYA eligibility and provisioning.