Shared Threat Intelligence Without Shared Data: Privacy-First Cross-Tenant Protection
When one organization discovers a new AI agent attack pattern, every other organization running similar agents is vulnerable to the same attack. Traditional threat intelligence sharing solves this by distributing Indicators of Compromise (IoCs) — IP addresses, file hashes, domain names. But AI agent threats do not look like traditional threats. There are no malicious IPs to blocklist. There are no file hashes to match. The attack is the agent's behavior itself.
This creates a tension: organizations benefit enormously from shared intelligence about agent attack patterns, but no organization wants to share data about what their agents are doing. The data is proprietary, sensitive, and potentially regulated.
MITRITY resolves this tension with an architecture where threat indicators are universal but matches are tenant-scoped. No tenant data leaves the tenant boundary. No tenant can see another tenant's agents, actions, or policies. Yet every tenant benefits from the collective detection capability of the entire platform.
The Architecture
MITRITY's threat intelligence system has three components: indicators, contributions, and matching. Each is designed with a specific privacy guarantee.
Indicators Are Universal
A threat indicator in MITRITY describes a behavioral pattern associated with a confirmed attack — not the specific data involved in any particular instance of that attack. Indicators have no tenant_id field. They exist outside any tenant's data boundary.
There are five indicator types, each designed for a specific class of AI agent threat:
Action Pattern Indicators. An ordered sequence of action types that, when observed in succession, indicates a likely attack. Example: [read_credentials, assume_role, list_instances, terminate_instance] — this four-step sequence is a common pattern in privilege escalation followed by resource destruction. The indicator captures the action types and their order, not the specific credentials, roles, or instances involved.
Behavioral Hash Indicators. A compressed representation of an agent's behavioral fingerprint during a confirmed attack. The behavioral hash encodes temporal patterns (when actions occur), frequency patterns (how often), and sequence patterns (in what order) into a fixed-size vector. Two agents exhibiting the same attack pattern in different organizations will produce the same behavioral hash, even though their specific actions target different resources.
Injection Signature Indicators. Patterns in agent instructions or tool parameters that indicate prompt injection or instruction manipulation. These are extracted from confirmed injection attacks, generalized to remove tenant-specific content, and stored as regex patterns or embedding signatures. Example: an indicator that matches the structural pattern of a "ignore previous instructions" injection without containing the specific text that was injected in any particular incident.
Tool Abuse Indicators. Patterns of tool usage that indicate misuse — not a specific tool being used, but a tool being used in a way that deviates from its intended purpose. Example: a database read tool being called with a SELECT * pattern across multiple tables in rapid succession, or a file write tool targeting system directories instead of application directories. The indicator captures the usage pattern, not the specific queries or file paths.
Delegation Pattern Indicators. Patterns in multi-agent delegation that indicate unauthorized scope expansion. When agent A delegates a task to agent B, and agent B further delegates to agent C with expanded permissions, the delegation chain may constitute an attack even if each individual delegation is within policy. These indicators capture the shape of the delegation graph — the number of hops, the permission expansion at each hop, and the relationship between the originating and final agents.
Contributions Are Anonymized
When a tenant's Edge Node detects and confirms a threat, the behavioral pattern can be contributed to the shared indicator set. This contribution process has strict anonymization requirements:
SHA-256 hashing. All identifiers — agent names, resource names, user IDs — are hashed with SHA-256 before leaving the tenant boundary. The hash is one-way: you cannot reconstruct the original identifier from the hash. The hash is also salted with a per-tenant secret, so the same agent name in two different tenants produces different hashes. This prevents cross-referencing.
Day-level timestamps. Exact timestamps are truncated to day-level granularity. An attack that occurred at 14:32:17 UTC is recorded as having occurred on 2026-02-18. This preserves temporal patterns (the attack happened on a weekday vs. weekend, during business hours vs. off-hours) while preventing correlation with specific operational events at a tenant.
Minimum threshold. An indicator is only created when the same behavioral pattern is observed across at least 3 different tenants and at least 10 total events. A pattern seen at only one or two tenants is not published as a shared indicator, even if confirmed as malicious. This threshold prevents indicators that could be reverse-engineered to identify a specific tenant. If a behavioral pattern is rare enough to be unique to one organization, it stays private.
No raw content. Indicators never contain raw action parameters, query text, API payloads, or any other content from agent actions. They contain only structural patterns: action types, sequence shapes, temporal distributions, and behavioral hashes. The distinction is critical — an indicator might say "an agent performed a database read followed by an external HTTP POST" but will never say "an agent read from the customers table and POSTed to https://attacker.com/exfil."
Matching Is Tenant-Scoped
The matching engine runs inside each Edge Node. When a new indicator is published to the shared set, it is distributed to all Edge Nodes. The Edge Node then matches incoming agent actions against the indicator set locally — within the tenant's boundary.
This design has an important property: the Edge Node does not need to know which tenant the indicator came from. Indicators are patterns, not events. The Edge Node checks whether the current agent's behavior matches the pattern, the same way an antivirus checks files against signatures without knowing which organization first discovered the malware.
Matching runs as a secondary check alongside DriftGuard. DriftGuard detects novel drift from an agent's baseline; the indicator set detects known-bad patterns from the broader community. Together, they provide both zero-day detection (DriftGuard) and known-threat detection (indicators).
When a match occurs, the alert is created within the tenant's data boundary. The alert references the indicator ID (a UUID with no tenant association) but all context — the agent name, the specific actions, the timeline — is tenant-private. No match data is sent back to the indicator system.
What This Means for Enterprises
Shared Defense Without Shared Data
Every organization on the MITRITY platform contributes to and benefits from a collective threat intelligence network. An attack pattern discovered at one organization is detectable at every other organization within minutes of confirmation — without any organization revealing what their agents are doing, what data they access, or how their systems are configured.
This is analogous to how antivirus signature databases work, adapted for the unique characteristics of AI agent threats. The "malware" is not a file — it is a behavioral pattern. The "signature" is not a hash of bytes — it is a structural description of the pattern. But the principle is the same: many organizations contribute detections, and every organization benefits.
Compliance-Compatible
The anonymization architecture is designed to satisfy data processing requirements under GDPR, SOC 2, and HIPAA. No personal data, no tenant-identifiable data, and no raw action data ever enters the shared indicator set. The minimum-threshold requirement provides k-anonymity: a pattern must be present at 3+ tenants before it becomes a shared indicator, making tenant identification from the indicator itself infeasible.
Organizations that need to opt out of contribution can do so without losing access to the shared indicator set. The matching engine is unidirectional — tenants always receive indicators regardless of whether they contribute.
Evolving Threat Coverage
AI agent attacks are a new and rapidly evolving threat category. No single organization has enough data to build comprehensive detection coverage alone. By pooling behavioral patterns across the entire MITRITY deployment base, the platform achieves detection coverage that scales with the number of participating tenants.
The more organizations that deploy MITRITY, the faster new attack patterns are identified, confirmed, and distributed. This creates a network effect: the platform becomes more valuable as adoption grows, without any individual tenant sacrificing privacy or competitive advantage.
Implementation Details
The shared threat intelligence system operates on three cycles:
Real-time (seconds). When an Edge Node confirms a match against an existing indicator, the match count is incremented (anonymously). This updates the indicator's confidence score and prevalence metrics.
Near-real-time (minutes). When a new threat is confirmed at a tenant and the anonymized behavioral pattern crosses the contribution threshold, a new indicator is created and distributed to all Edge Nodes. Typical propagation time from confirmation to global availability is under 5 minutes.
Periodic (daily). The indicator set is pruned daily. Indicators that have not matched in 90 days are deprecated. Indicators with high false-positive rates (based on anonymized dismissal signals) are downgraded or removed. New variant indicators are created when the ML pipeline detects mutations of existing patterns.
The Bigger Picture
Threat intelligence for AI agents is in its infancy. The attack surface is vast, the attack patterns are novel, and the tooling is immature. MITRITY's approach — privacy-preserving, behavioral, and collaborative — is designed to grow with the threat landscape.
As more organizations deploy autonomous agents and more attack patterns emerge, the shared indicator set becomes an increasingly valuable resource. Not because any single organization contributes more data, but because the aggregate behavioral signal across hundreds of organizations reveals patterns that no single organization could detect alone.
Shared defense. Zero shared data.
Learn more about MITRITY's threat intelligence capabilities in the product documentation, or start a free trial to see it in action.