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.
Noxtica checks the signature, key reference, and validity window. Each request resolves to a plain verification state: verified, unsigned, invalid signature, expired, or replayed. The result is recorded beside the risk read and contributes to it. A verified claim adds context. An invalid signature is a risk signal. Expired and replayed signatures are detected. Unsigned traffic stays unknown, not hostile.
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 and supported identity standards 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.
Who it fits
KYA helps you answer three questions about automated traffic.
- Which agents identify themselves? When it applies lists the four cases KYA separates. Outputs and decisions shows the result for each.
- Is this claim known to us? A verified claim that your team has not reviewed yet is the “Verified but unknown” row in Outputs and decisions.
- What should unknown traffic do? The fallback for unknown traffic is set out in When it applies.
How teams connect
KYA has no public sample code. Setup runs through your account team and depends on tenant provisioning. Three surfaces are involved:
- Request path. Supported signed requests are verified where your domains receive traffic. This needs compatible signing and an edge integration.
- Server verification. Your backend can ask Noxtica to verify an agent request with a server-held credential. Where provisioned, it can also carry verified agent context in an agent identity envelope. See Backend Integration and the Server API reference.
- Operator console. Review agent identity claims and verification results in the Agentic Security view of the console. Access follows operator role and tenant scope. See Risk actions, investigations and entity lookup.
Limits
Availability: Controlled availability. Eligibility and limitations and What KYA is not state most limits in full. This section adds the rest.
- Verify and observe today. Enforcement is roadmap and is not part of the offer described here. Any block or challenge based on agent identity is your own logic. Nothing here commits scope or date.
- Results are evidence. Your team makes the decision. Read the disclaimer.
Common questions
Does Know Your Agent block unwanted agents?
Not today. It verifies and observes. Limits states that enforcement is roadmap and that any allow, challenge, or deny decision stays in your own logic.
Is it the same as MCP or the AI Assistant?
No. What KYA is not sets out the differences.
What happens to agents that do not sign requests?
They stay unknown. Outputs and decisions shows the fallback to apply.
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.