Agentic Security
Definition. At Noxtica, “agentic” covers three distinct workflows: an operator can investigate tenant information with the AI Assistant, an external agent can read permitted tenant information through MCP, and a tenant can govern supported incoming agent identities with 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.
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.
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 and 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 — console investigation, current read-only scope, and eligibility.
- MCP Integration — tenant-scoped external read access.
- Know Your Agent — defensive agent identity and policy.
- Browser Security — customer-owned decisions and managed controls.
- Calibration — how to read score, confidence, and reasons together.
- Features: AI-assisted operations — the assistant and MCP customer surfaces.
- Features: agent identity and control — eligible incoming-agent governance.
- Backend integration — using risk outputs in your own application policy.