---
title: "Agentic Security"
description: "How Noxtica supports three bounded agent workflows: operator investigation, read-only MCP access, and governance of incoming automated agents."
canonical_url: "https://noxtica.com/docs/concepts/agentic-security/"
markdown_url: "https://noxtica.com/docs/concepts/agentic-security/index.md"
last_updated: 2026-09-11
published: 2026-06-15
section: "concepts"
section_title: "Concepts"
site: "Noxtica"
language: "en"
source: markdown
---

# Agentic Security

**Definition.** At Noxtica, "agentic" covers three distinct workflows: an operator can investigate tenant information with the [AI Assistant](https://noxtica.com/docs/concepts/ai-assistant/), an external agent can read permitted tenant information through [MCP](https://noxtica.com/docs/concepts/mcp-integration/), and a tenant can govern supported incoming agent identities with [Know Your Agent](https://noxtica.com/docs/concepts/know-your-agent/).

The problem is not a lack of automation. It is unclear authority. Security teams need to know whether an automated system is assisting an operator, reading a data source, or arriving as traffic—and which person or policy remains accountable in each case.

One boundary applies to all three meanings: Noxtica does not give an assistant or MCP client autonomous write access to customer systems. Read surfaces provide context for a human or customer-owned workflow. Traffic actions occur only through policy your team configures or code your team controls.

## When it applies

Use this model when:

- operators need a faster way to summarize policies, domains, recent activity, or risk;
- an internal AI workflow needs structured, read-only access to the same tenant-scoped context;
- product or security teams need differentiated treatment for supported automated-agent identities; or
- reviewers need to show who requested information and which policy caused a traffic action.

These are separate capabilities with separate eligibility. Adopting one does not activate the others.

## The three meanings

### 1. We operate agentically

Where the AI Assistant is available, a signed-in operator asks questions inside the console. The assistant can retrieve the same supported read-only surfaces the operator is permitted to view, such as policies, rules, domains, recent fingerprints, risk distribution, and audit information.

The output is a conversational summary for investigation. An operator uses it to choose which record, trend, or policy to inspect next. It does not change configuration or act on traffic. See [AI Assistant](https://noxtica.com/docs/concepts/ai-assistant/).

### 2. You integrate agentically

For tenants with MCP enabled, an operator issues a scoped credential and configures an MCP-compatible client with the provisioned connection details. The client can request allowed policies, rules, alerts, and risk distribution over the read-only MCP surface.

The output is structured tenant context that your agent can summarize or pass into a customer-owned review workflow. MCP does not expose write tools, and data from one tenant is not a cross-tenant intelligence feed. See [MCP Integration](https://noxtica.com/docs/concepts/mcp-integration/).

### 3. We police the agentic web

Where KYA is provisioned, a tenant records which supported agent identities it recognizes and how known, unknown, or denied agents should be treated. Noxtica evaluates the identity evidence presented with traffic; your application or configured enforcement policy decides whether to allow, observe, challenge, or block.

The output is identity and policy context, not a grant of authority and not proof that an agent's requested operation is safe. Apply normal authorization and business rules after the traffic decision. See [Know Your Agent](https://noxtica.com/docs/concepts/know-your-agent/) and [Browser Security](https://noxtica.com/docs/concepts/browser-security/).

## How the pieces compose

| Meaning                   | Customer entry point                                               | Output                                           | Decision owner                               |
| ------------------------- | ------------------------------------------------------------------ | ------------------------------------------------ | -------------------------------------------- |
| We operate agentically    | AI Assistant in an eligible operator console                       | Human-readable summary of permitted tenant state | Signed-in operator                           |
| You integrate agentically | Opt-in MCP connection with a scoped token                          | Structured, read-only tenant context             | Your agent workflow and its human owner      |
| We police the agentic web | KYA registry plus application or managed policy, where provisioned | Presented identity status and policy context     | Your application or configured tenant policy |

The assistant and MCP can help investigate why traffic was assessed a certain way. KYA can add agent identity context. Device risk, confidence, flags, route sensitivity, and your policy still determine the response. This separation keeps explanation, authorization, and enforcement reviewable.

## Outputs and decisions

Common customer outcomes include:

- reducing time spent locating the policy or traffic segment relevant to an investigation;
- feeding approved Noxtica context into an internal reporting or triage workflow;
- distinguishing a supported, verified automated-agent claim from an unknown or denied claim; and
- retaining a review path from risk evidence to the customer-owned action.

None of these outputs proves human identity, business intent, or permission to perform an application operation. Treat them as inputs to your existing access-control, fraud, and incident-response processes.

## Eligibility and limits

- The assistant remains read-only. Availability, quotas, and supported read surfaces depend on the provisioned plan and operator permissions.
- MCP is read-only, off by default, and tenant-scoped. Enablement and connection details are provided for eligible tenants.
- KYA and managed risk-action controls are not implied for every tenant or every agent identity scheme. Confirm supported deployment and provisioning before launch.
- Agents that do not present supported verifiable identity remain unknown; your policy must define the fallback.
- Native mobile attestation is a separate capability and is not included by the browser or agent concepts.

## Where we're headed

Today, humans set policies and thresholds. Self-calibration and feedback-driven tuning are being explored for future releases, but they are not part of the current contract. Any future write capability would require a separately documented permission and approval model; the assistant and MCP described here remain read-only.

## Read deeper

- [AI Assistant](https://noxtica.com/docs/concepts/ai-assistant/) — console investigation, current read-only scope, and eligibility.
- [MCP Integration](https://noxtica.com/docs/concepts/mcp-integration/) — tenant-scoped external read access.
- [Know Your Agent](https://noxtica.com/docs/concepts/know-your-agent/) — defensive agent identity and policy.
- [Browser Security](https://noxtica.com/docs/concepts/browser-security/) — customer-owned decisions and managed controls.
- [Calibration](https://noxtica.com/docs/concepts/calibration/) — how to read score, confidence, and reasons together.
- [Features: AI-assisted operations](https://noxtica.com/docs/features/#ai-assisted-operations) — the assistant and MCP customer surfaces.
- [Features: agent identity and control](https://noxtica.com/docs/features/#agent-identity-and-control) — eligible incoming-agent governance.
- [Backend integration](https://noxtica.com/docs/backend-integration/) — using risk outputs in your own application policy.