Dark
Request a walkthrough
On this page
Developer overview

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.

Key points

  1. A name is only a claimWhere KYA is provisioned, a tenant can compare supported cryptographic agent identity claims with its own known, allowed, or denied entries.
  2. Unknown needs a fallbackAgents without a supported identity path remain unknown and require a fallback policy.
  3. Allowed is not a bypassThe application still checks authentication, authorization, rate limits, and business rules.
  4. Not MCP, not the assistantMCP lets your external agent read approved Noxtica context; KYA evaluates agents arriving as traffic.
  5. Confirm eligibility firstDo not make KYA a launch dependency until the account team confirms eligibility and the intended agent identity path.
  1. When it applies
  2. How customers use it
  3. How Noxtica does it
  4. Outputs and decisions
  5. What KYA is not
  6. Eligibility and limitations
  7. Where it fits
  8. Who it fits
  9. How teams connect
  10. Limits
  11. Common questions
  12. Read deeper
How this page is organisedBar length shows each section’s share of the text. Select a section to jump to it.

  1. Traffic boundary

    An agent presents a claim

    An agent name or user-agent string is only a claim.

  2. Noxtica

    Supported evidence is verified

    Public cryptographic identity references instead of a display name.

  3. Your policy

    Compared with your entries

    Known, allowed or denied. Your fallback for unknown traffic matters as much as the allow list.

  4. Noxtica

    Managed enforcement

    Depends on tenant provisioning and deployment context.

    Where provisioned

From an agent claim to your trust policy

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:

  1. Inventory the automated agents that are expected to reach the protected domains.
  2. Record supported identity references and the tenant’s desired trust treatment.
  3. Define separate behavior for known, denied, and unknown claims.
  4. Observe matches and non-matches before introducing enforcement.
  5. Apply the result through customer-owned application logic or provisioned Browser Security controls.
  6. 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 stateWhat it meansCustomer decision
Verified and allowedSupported identity evidence matches an allowed tenant entryContinue to normal application authorization; allow or observe by route
Verified and deniedSupported identity evidence matches a denied tenant entryApply the tenant’s approved deny or challenge policy
Verified but unknownThe claim verifies but has no matching trust entryObserve, review ownership and purpose, then update policy deliberately
Invalid, absent, or unsupportedKYA cannot establish a supported identity matchFall 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.

Verified and allowed

What it means

Supported identity evidence matches an allowed tenant entry.

Customer decision

Continue to normal application authorization; allow or observe by route.

Verified and denied

What it means

Supported identity evidence matches a denied tenant entry.

Customer decision

Apply the tenant's approved deny or challenge policy.

Verified but unknown

What it means

The claim verifies but has no matching trust entry.

Customer decision

Observe, review ownership and purpose, then update policy deliberately.

Invalid, absent, or unsupported

What it means

KYA cannot establish a supported identity match.

Customer decision

Fall back to browser, device, network, and route policy.

Four output states and the decision that follows eachAn "allowed" result is not a bypass.

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