0%
Ingesting events
Company  ·  Security

Security practices for enterprise AI operations.

Review Xect AI's approach to access control, data protection, vulnerability management, and AI-specific risk. Each control is mapped against publicly documented attack techniques for AI and LLM systems, tracked against Xect's own architecture and cataloged in the technical appendix below.

Access, data & AI-specific controls75-technique technical appendixVulnerabilities assessed by severity

No amount of proactive testing makes any platform completely safe, and this page does not claim otherwise. What it documents instead: each technique in the appendix below is tracked against Xect's own architecture, mapped to a specific mitigation running today, and re-verified as the wider threat landscape shifts.

Where a technique doesn't yet have a shipped mitigation, it doesn't appear here as "protected." New vulnerabilities are assessed by severity as they're identified, with remediation prioritized accordingly rather than held to a release calendar.

This page covers Xect's response to known AI attack techniques. For the platform's access-control, multi-tenancy and audit architecture, see Security & Governance.

Technical appendix

Mitigations mapped to each stage of an attack

Ten stages, from the first scouting to the final payoff, drawn from publicly documented AI attack research. Click a stage to see the techniques it covers and the mitigation Xect runs against each one today.

01
Combing public research for clues about our stack

Xect's approach: Model names, versions and infrastructure details are kept out of documentation and marketing material where disclosing them could help an attacker target the stack.

02
Tracking published vulnerability research to shortcut an attack

Xect's approach: The security team tracks new AI vulnerability research daily. Findings are assessed by severity, with remediation prioritized accordingly.

03
Mining our own public pages for technical detail

Xect's approach: Site content is reviewed before publishing to limit technical stack details that could aid targeting.

04
Scanning app listings for architecture clues

Xect's approach: Xect ships no public app-store binaries or manifests that could expose model or agent architecture.

05
Probing our network for exposed AI services

Xect's approach: Agent infrastructure sits behind network segmentation and firewalls, with anomaly detection on inbound scanning patterns.

06
Hunting for a fabricated link or package an agent might invent

Xect's approach: Agent-generated references (a URL, a package, a contact) are checked against the Knowledge Graph or a connector before reaching a user.

07
Reading raw scores never meant to leave an API response

Xect's approach: API responses return only the fields an integration needs. Raw confidence scores and logits stay internal to the agent runtime; any confidence value exposed through an API is rounded to limited precision.

08
Mapping which sources feed our retrieval systems

Xect's approach: Knowledge Graph source configurations stay internal, and query patterns are monitored for enumeration attempts.

09
Coaxing a model into revealing its own instructions

Xect's approach: System prompts run on a separate trusted channel, isolated from user input, with injection detection on every incoming query.

10
Getting an agent to disclose its own tools or permissions

Xect's approach: Agent configuration and tool lists are access-controlled and never disclosed through the agent's own responses.

01
Pulling model files or configs from exposed storage

Xect's approach: Cloud storage and code repositories are audited on a schedule, with secret scanning on every commit.

02
Rebuilding a stand-in model to rehearse an attack offline

Xect's approach: Rate limiting and query watermarking on every inference and connector call make offline replication of Xect's behavior impractical.

03
Standing up servers and domains to stage an attack

Xect's approach: Threat-intel feeds are monitored continuously for lookalike domains and infrastructure staged against Xect's brand.

04
Picking up existing attack tools built for AI systems

Xect's approach: Public AI attack toolkits are run against Xect's own agents in scheduled red-team exercises.

05
Building custom attack tooling from scratch

Xect's approach: Anomaly detection on inference patterns is tuned to catch novel attack development, not just known signatures.

06
Seeding a public dataset with hidden corruption

Xect's approach: Every dataset the Knowledge Graph ingests comes from a vetted, provenance-tracked source, never an unverified public repository.

07
Creating accounts to stage or disguise an attack

Xect's approach: Contributors to the Knowledge Graph and shared model resources are identity-verified, and artifacts are signed.

08
Uploading a backdoored model to a public registry

Xect's approach: Every third-party model or connector Xect integrates is pinned to a version and checksum-verified before deployment.

09
Pre-positioning malicious files on infrastructure or public platforms

Xect's approach: Public repositories are monitored for artifacts impersonating Xect, and every external download passes an integrity check.

01
Compromising a vendor or dependency upstream of the model

Xect's approach: Every component of the agent stack, from connector to model call, passes a supply-chain security review before it ships.

02
Tricking someone into running a compromised file

Xect's approach: Model and agent artifacts are code-signed, and staff are trained to recognize social engineering aimed at AI workflows.

03
Using stolen or leaked credentials to log in

Xect's approach: MFA is enforced on every platform account, API keys rotate on a schedule, and anomalous credential use is flagged automatically.

04
Abusing a legitimate API key to reach the model

Xect's approach: Every inference call is authenticated, rate-limited per key, and logged for behavioral anomaly detection.

05
Tampering with the sensors feeding a model

Xect's approach: Sensor and data-collection infrastructure feeding Xect's telemetry agents is physically secured and cross-checked across sources.

06
Reaching the model indirectly through a product built on it

Xect's approach: Model-related metadata is stripped from every public-facing API response before it leaves the platform.

07
Exploiting a bug in a public-facing application

Xect's approach: OWASP-standard secure development practices, a web application firewall, and scheduled penetration testing cover every public endpoint.

08
Slipping adversarial instructions into ordinary input

Xect's approach: User input is sanitized and scored for injection patterns before it ever reaches an agent's instruction channel.

09
Phishing a person who holds access to the system

Xect's approach: Email security gateways with AI-phishing detection, plus DMARC, DKIM and SPF, protect every account with platform access.

10
Hiding instructions in a web page an agent reads

Xect's approach: Web content an agent retrieves is sanitized and checked against an allowlist before it can change agent behavior.

01
Abusing a shell or script interpreter available to the system

Xect's approach: Interpreter access from agent processes is sandboxed, with allowlisted commands and every invocation logged.

02
Tricking an agent into calling a tool it shouldn't

Xect's approach: Every tool an agent can call is scoped to least privilege, and high-risk invocations require an explicit human-in-the-loop approval before they run.

03
Opening a covert outbound channel for remote control

Xect's approach: Outbound connections from agent infrastructure are egress-filtered and monitored, with endpoint detection running on every hosting system.

01
Finding internal model or data stores once inside

Xect's approach: Internal artifact stores are access-controlled and inventoried, with alerts on unusual bulk access.

02
Enumerating everything a model can classify or output

Xect's approach: Queries that systematically probe output diversity are rate-limited, and API responses return only the classes an integration needs.

03
Fingerprinting which model architecture is running

Xect's approach: Outputs are abstracted and post-processed before they leave the runtime, so no response is designed to reveal underlying model details.

04
Enumerating cloud AI services after gaining a foothold

Xect's approach: IAM policies are least-privilege by default, and cloud audit logs are monitored for unexpected service enumeration.

01
Collecting models, datasets or logs for later theft

Xect's approach: Models, datasets and interaction telemetry are encrypted at rest with role-based access and DLP policies.

02
Mining internal wikis and databases for useful data

Xect's approach: Need-to-know access controls and audit logging apply to every information repository an agent can reach.

03
Searching local files and configs for secrets

Xect's approach: Agent hosts store minimal sensitive data locally; secrets live in a vault, never in a configuration file.

04
Pulling credentials accidentally stored in retrieval sources

Xect's approach: Documents are scanned and redacted for credentials before they ever enter the Knowledge Graph.

05
Reading API keys straight out of an agent's config

Xect's approach: API keys and tokens live in a secrets manager, never in an agent's own configuration file, and rotate on a schedule.

06
Using an agent's own access to reach data a person couldn't

Xect's approach: Data access is scoped per tool and per agent role, and every retrieval is logged and auditable.

01
Testing an attack quietly before using it for real

Xect's approach: Rate limiting and behavioral detection flag the systematic query patterns attackers use to verify an attack offline.

02
Engineering input designed to fool a model

Xect's approach: Input preprocessing defenses run on every request, and adversarial robustness evaluations happen on a recurring schedule.

03
Getting complete offline access to a model's weights

Xect's approach: Model weights are encrypted and access-controlled; large binary transfers consistent with weight exfiltration trigger an alert.

04
Iterating a prompt until it reliably breaks the rules

Xect's approach: Guardrail prompts are refreshed continuously, and adaptive filtering learns from every detected injection attempt.

05
Writing content meant to be pulled into a retrieval system

Xect's approach: Retrieved content is filtered for injected instructions before an agent ever sees it, with full provenance tracking.

01
Slipping past a classifier undetected

Xect's approach: Security-critical decisions run through multi-model verification rather than a single classifier's word.

02
Directly altering a model's weights or files

Xect's approach: Every deployed model file is signature-verified, and only an authorized CI/CD pipeline can write to model storage.

03
Planting a backdoor inside the training data itself

Xect's approach: Data provenance checks and anomaly detection run across every pipeline before a dataset trains or updates a model.

04
Flooding a service until it falls over

Xect's approach: Rate limiting, request throttling and auto-scaling with budget caps keep a flood of requests from taking a service down.

05
Quietly degrading model accuracy over time

Xect's approach: Model performance is monitored continuously; unexpected drift triggers an automated retraining review, not a slow discovery months later.

06
Running up the compute bill with wasteful queries

Xect's approach: Hard budget caps, spending alerts and per-key query quotas cap the damage a high-volume abuse pattern can do.

07
Burying real alerts under a flood of noise

Xect's approach: Confidence thresholds and deduplication keep low-quality alerts from burying a human reviewer's queue.

08
Using the system to produce harmful output at scale

Xect's approach: High-risk AI-generated content passes output filtering and human review before it reaches an external party.

09
Corrupting a dataset until it's no longer trustworthy

Xect's approach: Dataset versioning and integrity hashing make a corrupted record visible immediately, not after it's already trained a model.

10
Crafting a file that evades scanners but still executes

Xect's approach: Model files are scanned by both static signature checks and a behavioral sandbox before anything is trusted in production.

01
Rebuilding private training data through repeated queries

Xect's approach: Confidence scores returned to callers are limited in precision, and query patterns consistent with model extraction are flagged automatically.

02
Moving stolen artifacts out over the network

Xect's approach: DLP controls on network egress and encryption at rest cover every AI artifact and dataset the platform holds.

03
Smuggling data out through an agent's own tool calls

Xect's approach: Tool-call parameters are inspected for encoded data, and high-impact or policy-flagged actions require human approval before an agent can send data to an external destination.

01
Talking a model past its own safety rules

Xect's approach: Input filters, output filters and in-model alignment stack together, and every agent is red-teamed against current bypass techniques on a recurring schedule.

02
Finding plaintext secrets left in a compromised system

Xect's approach: Every credential lives in a secrets manager; automated scans catch anything hardcoded in code or configuration before it ships.

03
Extracting the hidden instructions behind a model's replies

Xect's approach: System prompts are encrypted, access-restricted, and monitored for responses that reproduce them verbatim.

04
Coaxing out training data or another user's session

Xect's approach: Output scanning redacts sensitive patterns before a response leaves the agent, and session isolation keeps one user's context from leaking into another's.

05
Registering a fake link or package a model once invented

Xect's approach: AI-generated references are checked against source material and citation-verified before being presented to a user.

06
Making an instruction copy itself into every downstream response

Xect's approach: Outputs that feed into another agent's input are scanned and sanitized first, with context isolation between sessions and tool calls.

07
Faking a citation or link to look more credible

Xect's approach: Links, citations and recommended actions are validated against trusted sources before display, with UI-level warnings on anything unverified.

08
Hiding malicious instructions in invisible text or encoding

Xect's approach: Inputs are normalized and decoded before injection detection runs, so hidden characters and encoding tricks don't slip past it.

09
Contaminating a retrieval source so future answers are false

Xect's approach: Every document is validated and sanitized before it enters the Knowledge Graph, and retrieved content is checked for injection patterns at query time.

10
Smuggling a fake authoritative document into retrieved context

Xect's approach: Strict schema validation on every Knowledge Graph entry catches content trying to impersonate a separate authoritative document.

11
Posing as a trusted source or publisher

Xect's approach: Every artifact Xect publishes is cryptographically signed, so a lookalike model or registry entry can't pass as an official release.

12
Disguising a malicious file to look legitimate

Xect's approach: Artifacts are verified by checksum and signature, never by file name, and scanned regardless of what they claim to be.

13
Hiding a data-exfiltration trick inside a rendered response

Xect's approach: Agent output is sanitized and render-escaped before display, with a Content Security Policy blocking unauthorized outbound requests.

14
Planting a false memory that persists across an agent's sessions

Xect's approach: Agent memory is isolated per session and validated before reuse, with monitoring for behavior that persists past a single legitimate instruction.

15
Rewriting an agent's own configuration to corrupt its behavior

Xect's approach: Agent configuration changes go through version control and mandatory review, with file integrity monitoring alerting on anything unauthorized.

Security is a continuous practice, not a one-time certification. This landscape keeps shifting as new adversarial ML research emerges, and Xect's security team reviews new findings against its own architecture on an ongoing basis.

Found a technique Xect doesn't yet mitigate, or a gap in one of the entries above? Tell us and we'll review it.

Request the evidence behind these controls.

Book a session with Xect's security team to review control mappings, audit findings and assurance documentation relevant to your deployment.

The attack stages referenced on this page are informed by the ATLAS™ knowledge base (atlas.mitre.org). Copyright © The MITRE Corporation, licensed under the Apache License, Version 2.0. Reference to this material does not imply MITRE's endorsement of Zect AI or its Xect platform.