Member of AI & Innovation

We leverage the strength of our global team, knowing we’re more powerful together. Read news about Gen's company activities and initiatives.

Company News

AI is rapidly shifting from something we interact with into something that can act on our behalf. We can ask AI to research, shop, plan, create and get things done for us. And increasingly, AI agents are connecting with the apps and services we already use – accessing information and learning our preferences to make those experiences more useful and personal.&nbsp;And that shift is happening fast. New Gen telemetry shows nearly one in three desktop users are now interacting with agentic AI services.&nbsp;That potential is exciting – but there’s an important tradeoff: The more AI can do for us, the more it may need to know about us.&nbsp;Today, Gen is addressing that tradeoff with the launch of the <a href="https://ai.gendigital.com/" target="_blank" rel="noreferrer noopener">AI Data Checker</a>, a new tool within its Agent Trust Hub, designed to help people better understand how AI apps and agents may interact with their data.&nbsp;<h2>AI is getting more personal. So is the data it uses.&nbsp;</h2>AI agents and apps represent an important shift in our relationship with technology. As our chatbots have evolved to take on more of our complex tasks, they may connect with other apps, remember preferences and use personal context to deliver more personalized experiences.&nbsp;While this information makes AI so useful, it also raises important questions.&nbsp;What data does an AI service collect? What can it access? How might that information be used? Is it retained? Could it be used for training, personalization or advertising?&nbsp;The answers may exist somewhere in privacy policies and terms of service, but finding and understanding them isn't always easy. We believe it should be.&nbsp;

<h2>Introducing the AI Data Checker&nbsp;</h2>The AI Data Checker is designed to make your relationship with AI safer and more transparent.&nbsp;As part of Gen's Agent Trust Hub, the tool helps people get greater visibility into how their data may be handled by the AI apps and agents they use.&nbsp;The Agent Trust Hub is Gen's broader effort to help people navigate an increasingly agentic internet with greater visibility, understanding and protection. Since launching in February, it has expanded to include technologies such as VPN for Agents, purpose-built for autonomous agents, and Sage, Gen's consumer agentic security layer available through Norton AI Agent Protection in Norton 360. AI Data Checker adds another piece to that work: helping people understand the data relationship behind the AI tools they use.&nbsp;The AI Data Checker builds on the tools already available through the Agent Trust Hub, which explores the data practices of popular AI services and helps translate complex policies into information people can more easily understand.&nbsp;Using the AI Data Checker is simple: Enter your email address or username and the tool checks where that information may appear across AI services, helping you uncover which apps may have your data and understand what they can do with it. From there, you can explore individual services to see how they handle data — including whether information may be used to train AI, personalize advertising or be retained — and dig deeper into the policies behind those practices. The tool also scans for non-AI accounts where you may have connected and potentially shared personal information.&nbsp;The Agent Trust Hub also lets people paste in the URL of an AI app or its terms page to scan the text and get a clearer picture of what they may be agreeing to.&nbsp;The goal is simple: Help people understand what they're sharing with AI, how that information may be used and what choices they have.&nbsp;People shouldn't need to be privacy experts to understand what happens to their information.&nbsp;<h2>What some apps allow&nbsp;</h2>The convenience of AI agents can come with data practices people may not expect.&nbsp;Take Instinct, a personal AI assistant that can connect to other services and take actions on a user's behalf. According to <a href="https://us.norton.com/blog/ai/is-instinct-safe" target="_blank" rel="noreferrer noopener">an analysis of Instinct's terms</a>, information shared with the assistant may be used to train AI models unless a user opts out or uses its protected Vault feature. And connecting another account can have implications beyond the connection itself: Instinct's terms state that even after a Connected Service is disconnected, previously indexed data from that service may still be used unless the user takes additional steps to request its deletion.&nbsp;Then there is what an agent can do with that access. Instinct can make purchases on a user's behalf using payment information they've provided. Its terms make clear that those purchases are treated as purchases made by the user – and disputes are between the user and the relevant merchant.&nbsp;Other AI services illustrate different kinds of data tradeoffs. Replika, for example, says it may collect information including location, contact information, identifiers and usage data. Apple's privacy disclosure for the app also says certain identifiers and usage data may be used to track users across apps and websites owned by other companies. Replika's own privacy policy says information about visits to its website may be shared with advertising partners for interest-based advertising, although conversations and content provided within the app are not shared with advertising partners.&nbsp;These practices aren't all equivalent, and they don't necessarily mean a service is unsafe, but they may raise red flags for people who value their data and privacy.&nbsp;<h2>Useful AI shouldn't require blind trust&nbsp;</h2>Data itself isn't the enemy. AI agents need context to be useful. An agent helping organize your day isn't very helpful if it can't see your calendar. An agent helping plan a trip may need to know where you're going and your travel preferences. An agent helping manage your inbox needs access to your messages.&nbsp;The answer isn't AI that knows nothing about us. It's giving people greater visibility, understanding and control over what they choose to share.&nbsp;People should be able to make informed decisions about which AI services they trust, what information they give them and how that information is used.&nbsp;At Gen, we believe people should be able to embrace what AI makes possible while remaining informed and in control of their digital lives.&nbsp;The more AI knows about us, the more important it becomes for us to understand what it knows – and what happens to that information. That visibility can help people use AI with greater confidence and live fearlessly in an increasingly agentic world.

As AI agents become more central to our digital lives, Gen is empowering people to understand and control how AI agents access, use and share their data 

Gen Launches AI Data Checker as Part of Its Agent Trust Hub 

Security Evangelist at Gen

Gen has a family of trusted consumer brands that for decades have helped people stay safe in the digital world. We pride ourselves in the trust we’ve built with people around the world to navigate the latest technology safely and with confidence. And that’s exactly why we recently launched the Gen Agent Trust Hub – our trust layer for the agentic AI ecosystem.AI agents are no longer theoretical. They are here. They are editing files, installing packages, calling APIs, connecting to MCP servers, spawning sub-agents, persisting memory, and executing real workflows across environments. This shift from passive AI to autonomous execution fundamentally expands the attack surface.The Agent Trust Hub (ATH) exists to meet this moment. It is designed to provide continuous protection across the full lifecycle of an AI agent – from identity and verification to runtime enforcement. But security at this scale cannot rely on proprietary guardrails alone. It requires shared foundations the industry can build on.To help establish that foundation, we created the AI Agent Safety Standards by Gen to serve as a unified framework designed to bring consistency, portability, and accountability to agentic systems. This framework is currently built on two complementary pillars:<ul type="disc"><li data-list-item-id="e464ce0354d35c1a986c83945bc06b0cd">AI Agent Runtime Safety Standard (AARTS) – an open standard for runtime decision enforcement across agent hosts</li><li data-list-item-id="e4a7d4ceb7039019b7c2554401a8bb1c3">Skill IDs – a deterministic, content-addressable fingerprinting system for AI agent skills</li></ul>Together, they enable the ATH and the broader agentic AI community to enforce trust not just within one environment but across the broader agentic ecosystem. &nbsp;Let’s dig into the details.&nbsp;<h2>Pillar One: Standardizing Runtime Safety for AI Agents</h2><h3>AARTS</h3>AI agents operate across a fragmented ecosystem of IDEs, orchestrators, frameworks, and standalone applications. Each host defines its own lifecycle events, security hooks, and enforcement logic.This fragmentation creates blind spots. A security engine integrated into one host may lack context or control in another, even when the risks are identical.AARTS&nbsp;addresses this gap. It is not a product. It is a vendor-neutral contract that defines:<ul type="disc"><li data-list-item-id="e226fc797549b56b0ae0a537923fd79f6">Where security decisions can be made (hook points)</li><li data-list-item-id="e7566ceb595a0278da9453bbd84659578">What data is available for evaluation (data model)</li><li data-list-item-id="e637f36bcc4e8dcfac7321ad59230c1c1">How decisions are enforced (verdict semantics)</li></ul>Simply put:&nbsp; AARTS standardizes runtime security decision-making across agent hosts.<h3>The Architecture</h3>AARTS defines three cleanly separated roles:<ol><li data-list-item-id="e7a445b9a896b9b89299afa17ca58c69e">Host Runs the agent, emits lifecycle events, and enforces decisions.</li><li data-list-item-id="e989b722cd161ff069c924d70571cd6b7">Adapter Maps host-native events into a standardized AARTS schema.</li><li data-list-item-id="ed862f4398b4b82c3b52c721801728a9c">Security Engine Evaluates events and returns structured verdicts.</li></ol>This separation prevents superficial “checkbox security” while preserving portability. Hosts provide the right context at the right time. Engines make decisions without depending on host internals.In ATH, this architecture allows enforcement logic to remain portable while enabling hosts to integrate in a predictable way.<h3>Hook Points: Where Safety Happens</h3>AARTS v0.1 defines 19 hook points across the agent lifecycle, including:<ul type="disc"><li data-list-item-id="ec5255705352d810833f77d79b310a42d">PreToolUse — evaluate shell commands, file writes, web requests, package installs</li><li data-list-item-id="ee1ebbdf3e4522a59dedaa55c0305d903">PreLLMRequest — protect prompt integrity and instruction layering</li><li data-list-item-id="e10ef155bfe4c584afd7492da267796be">PreSkillLoad / PrePluginLoad — enforce supply chain controls</li><li data-list-item-id="ee6184f1048dfbf4ee3c0e62c2d3dff16">PreMCPConnect — treat MCP connections as trust boundaries</li><li data-list-item-id="ebc57267bf0e891e01f9daf277ced1a01">PreMemoryRead / PreMemoryWrite — protect persistent memory</li></ul>These hooks enable consistent policy enforcement regardless of whether an agent runs in an IDE, CLI, or orchestrator.Verdict Semantics: Allow, Deny, AskAARTS engines return structured verdicts:<ul type="disc"><li class="ck-list-marker-bold" data-list-item-id="e9615d2d55e251652e73363c052de0bd1">Allow</li><li class="ck-list-marker-bold" data-list-item-id="eb510a0ee27b0a853b90ff01cec91953d">Deny</li><li class="ck-list-marker-bold" data-list-item-id="ed6e8c58ce99af62dddbf6b530bc0c83c">Ask</li></ul>Each verdict includes severity, threat category, optional confidence scoring, and human-readable reasoning.Importantly, AARTS enforces deterministic behavior:<ul type="disc"><li data-list-item-id="edfce7cb3a277e1da6e442c971f8cc8e1">If a host cannot support interactive “Ask,” it defaults safely to Deny</li><li data-list-item-id="ec790330b39c695d6cdacf4118e106c1b">If an engine fails, hosts fail-open and log explicitly</li></ul>These operational tradeoffs are intentional. Predictability is essential in security infrastructure.<h3>Why AARTS Matters</h3>Without a shared runtime contract:<ul type="disc"><li data-list-item-id="e2574817ec2bfc1a1b0233c5fca970994">Security integrations are bespoke and brittle</li><li data-list-item-id="ebbe5c354debe741cc08436719a34032e">Tool taxonomy is inconsistent</li><li data-list-item-id="e2f498a30e5d748e37c3176b169145707">Prompt injection controls vary by host</li><li data-list-item-id="e3aff5387909fd85f523c40998fdb13b0">Supply chain risk is unevenly enforced</li></ul>With AARTS:<ul type="disc"><li data-list-item-id="eaa8f402b20b740f0992dd0f9b4f42b44">One engine can operate across multiple hosts</li><li data-list-item-id="e3ddcda4fa65f1abd066be4b0bef0201b">Policies remain portable</li><li data-list-item-id="e5ec3076209374ae5eafb39a00f19adf4">Audit logs become comparable</li><li data-list-item-id="e6f17fa0cc0a6a6e0136b63569cdc58a6">Trust boundaries are explicit</li></ul>AARTS standardizes enforcement in the agentic world.To read the full technical breakdown, see the full AART&nbsp;<a href="https://www.gendigital.com/blog/news/company-news/ai-agent-runtime-security">technical blog post</a>. To comment on the standards, visit our page on&nbsp;<a href="https://github.com/gendigitalinc/aarts">GitHub</a>.<h2>Pillar Two: Skill IDs</h2><h3>Fingerprinting AI Agent Skills</h3>AI agents are extended through skills – directory bundles containing a SKILL.md prompt file alongside scripts, templates, configuration, and documentation.These skills function like plugins. Install one, and the agent gains new capabilities.But skills are not single files. They are directory trees.And directory trees are notoriously difficult to fingerprint reliably.<h3>The Identity Problem</h3>A naive SHA-256 hash of a ZIP file does not work:<ul type="disc"><li data-list-item-id="e6fc83ba16d130bd7d3d62ba2af79f96d">ZIP files are non-deterministic</li><li data-list-item-id="ee7939e0ca570cb480cbdc5b8e5460ece">Timestamps vary</li><li data-list-item-id="e5d398fbba0c41d53d0e3782902bce4c1">Entry order differs</li><li data-list-item-id="e95611c8e95e6ad4f16eccdede99ac42c">Unicode normalization differs across OS platforms</li><li data-list-item-id="ef8771bdef58d5438cc192edc36e89c56">Wrapper directory names vary</li></ul>Two identical skills can produce different ZIP hashes.That is unacceptable for security workflows.<h3>Designing the Skill ID</h3>Skill IDs solve this problem by creating a deterministic, content-addressable identifier for a skill’s logical directory tree.The algorithm:<ol><li data-list-item-id="ebdc8f7c1fc531f4ccbd79f2baf7b6d83">Extract all files and directories</li><li data-list-item-id="e06cf4d178c29a57575a249d22d5cb9b4">Normalize paths (slashes, Unicode NFC, dot components)</li><li data-list-item-id="e69f139d48a1c91815267ffb649c74e07">Strip wrapper directories</li><li data-list-item-id="e07c1da87b4b07a634d73a79ab93f9134">Hash each file individually (SHA-256)</li><li data-list-item-id="ef7cb735107df0cafdbcc921e639c0212">Build sorted tree entries using null-byte delimiters</li><li data-list-item-id="eab8b3782aab3b4dd9b0f4aed3255caf8">Hash the tree to produce the final Skill ID</li></ol>The result is a 64-character SHA-256 digest that changes if and only if meaningful content changes.Same content, different ZIP packaging? Same ID. One byte changed? Different ID.This mirrors git’s tree hashing model and decades of security best practices.<h3>What Skill IDs Enable</h3>A stable identity primitive unlocks established security workflows:Allowlisting Approved skills can bypass repeated analysis.Content-addressable storage Deduplicate identical submissions automatically.Per-file caching Reuse expensive AI analysis on unchanged files.Detection flagging Connect file hashes to reputation systems.Version tracking Content becomes the version boundary.Skill IDs provide identity before verdict.<h3>From Identity to Authenticity: Signing Skills</h3>Identity answers “what is this?”Authenticity answers “who published this?”We are exploring a signing model inspired by Authenticode:<ul type="disc"><li data-list-item-id="e2103c63753a0f24a87fa144d75611c7a">A skill.sig file embedded inside the directory</li><li data-list-item-id="e28e6643465e0cabeea54eb4bc5302028">Excluded from the Skill ID calculation</li><li data-list-item-id="e700fd96bf7f3d0db4aa70df0a92d57ec">Contains a signature over the Skill ID</li><li data-list-item-id="ea2483e766cae2defa9d2dd19707d9302">Verifiable against the author’s public key</li></ul>This enables:<ul type="disc"><li data-list-item-id="eddf73c0b79d7d482c030736b4f449be8">Author signing</li><li data-list-item-id="e3d708097518f6e38a31a73aaf27ecb49">Marketplace attestation</li><li data-list-item-id="e81ca5157252eece76405ff632c0d6722">Certificate chains</li><li data-list-item-id="efe336aa9f477f99f141fc5a81f887d9b">Revocation workflows</li></ul>Self-verifiable skills create accountability without external lookups.To read the full technical breakdown, see the full <a href="https://www.gendigital.com/blog/insights/research/ai-agent-skill-fingerprinting" target="_blank" rel="noreferrer noopener">SkillsID technical blog post</a>. To comment on the standards, visit our page on <a href="https://github.com/gendigitalinc/skill-id-standard">GitHub</a>.&nbsp;<h2>The AI Agent Safety Standards by Gen: Identity + Enforcement</h2>AARTS governs runtime enforcement. Skill IDs govern artifact identity.Together, they form the foundation of the AI Agent Safety Standards.<ul type="disc"><li data-list-item-id="ea3ef208939f34e4fcfaf98bd8e26b2d6">Skills can be uniquely identified, versioned, and signed.</li><li data-list-item-id="e30dceebd279e7a291dc71a82c7168ab2">Runtime actions can be evaluated consistently across hosts.</li><li data-list-item-id="e1a7b0d4259c4abb5e6ba2f38dffd6aaa">Supply chain trust and runtime enforcement operate under shared semantics.</li></ul>This is the same model that matured endpoint security over decades:<ul type="disc"><li data-list-item-id="ebacb70fb4a6565c103650a6c6ee67532">File hashes</li><li data-list-item-id="ed254dd1eec0c62e2aea6bce82e871995">Content signatures</li><li data-list-item-id="e37a3133a17b4a1adca017b868990baa6">Runtime enforcement</li><li data-list-item-id="eeeb5f5d7a84badb31f60600269d24edf">Portable policy engines</li></ul>We are applying those proven patterns to a new artifact type and a new execution model.<h2>Looking Ahead</h2>These standards are early. AARTS v0.1 is a draft. Skill ID signing is an evolving proposal. Adapter conformance testing, enterprise fail-open profiles, and cross-marketplace reputation sharing remain active areas of collaboration.But the direction is clear.AI agents are moving from experimentation to infrastructure. Security must do the same.The Gen Agent Trust Hub is our contribution to building a predictable, interoperable trust layer for the agentic ecosystem.&nbsp;We invite host builders, marketplace operators, enterprise security teams, and fellow security vendors to review, adopt, and challenge.Because in the agentic era, safety cannot be bespoke. It must be foundational.&nbsp;

Shaping the standards for a safer, freer Agentic Era 

Leading the Way for AI Agent Safety 

Director of Threat Research & Applied AI

We built a security engine that protects AI agents across several major platforms. The hardest part wasn't building the protection. It was discovering that each platform exposes different security-relevant events, provides different context about what the agent is doing and why, and enforces security decisions differently. The same agent action we can catch and block in one platform is invisible in another, not because our detection failed, but because the platform never told us it happened. There are now over a dozen agent platforms, from IDE assistants like Claude Code, Cursor, and GitHub Copilot, to agentic frameworks like LangChain, CrewAI, and OpenAI Agents SDK, to orchestrators like n8n, and each one handles this differently, if at all.Today, Gen is releasing AI Agent Runtime Safety Standard (AARTS) as part of its Agent Trust Hub initiative, which aimsto address this fragmentation. This is not a security product, but rather a set of vendor-neutral standards that connects agent hosts (IDEs, orchestrators, frameworks, standalone agent apps), security engines (components that evaluate agent actions), and adapters (thin mappings that translate host-native events into a common schema). For those building or operating agents, AARTS enables portable, consistent security decisions across hosts, eliminating the need to rebuild security integrations from scratch.&nbsp;The standard is open and vendor-neutral, and any host or security vendor can implement or contribute to it.<h2 class="text-align-justify">The Problem AARTS Addresses</h2>Agentic systems fail in ways that are familiar but occur more rapidly and with greater reach. Examples include sequences evolving from helpful actions to dangerous activities like&nbsp;"download and execute," prompt injection steering tool use, supply chain issues affecting skills and plugins, sensitive data exposure by agents, and permission confusion resulting from sub-agents and external tool providers creating additional trust boundaries. Although these risks are not new, they now manifest within a rapidly diversifying set of hosts and tool APIs.Without a shared contract, security becomes a collection of one-off integrations, each missing context and offering inconsistent enforcement. This leads either to weak coverage, due to incomplete integrations and context, or to overly blunt blocking when trust is undermined by limited interpretation. AARTS targets the root cause: the lack of shared semantics and hook points.In our previous&nbsp;<a href="https://www.gendigital.com/blog/news/company-news/ai-agent-detection-and-response" target="_blank">post on Agent Detection and Response</a>, we described how attackers register AI-hallucinated package names on npm and PyPI, preloaded with infostealers. Catching that requires seeing the package install action with enough context — the package name, the source, whether the agent hallucinated it or the user requested it. One platform gives us all of that. Another gives us the command string with no structured metadata. A third doesn't emit the event at all. Same attack, three different levels of visibility.Simply put, AARTS standardizes where security decisions can be made (hook points), what data is available for decision-making (data model), and how decisions are enforced (verdict semantics), ensuring consistent protections across different agent hosts.<h2 class="text-align-justify">Architecture and Roles</h2>AARTS defines three distinct roles:<ul type="disc"><li data-list-item-id="ef43f78807d68ed5d7cafc41e43ed6a77">Host: The environment that runs the agent. The host emits lifecycle events at defined hook points and enforces decisions.</li><li data-list-item-id="ea8ecfedda9151e1e4ff45954fc0bd003">Adapter: A minimal translation layer that maps host-specific events into AARTS events, normalizing tool names, lifecycle phases, and context.</li><li data-list-item-id="ec84e412023baa1359b60a4c189c0ce73">Security Engine: The evaluator that receives AARTS events, applies detection strategies, and returns structured verdicts.</li></ul>This separation matters. Embedding security logic in hosts results in superficial security ("checkbox security"), while engines depending on host internals compromise portability. AARTS keeps the boundary clean: hosts provide the right moments and context, and engines make decisions. AARTS also supports various integration models (in-process, subprocess, remote), accommodating different latency, isolation, and operational requirements.<h2 class="text-align-justify">How the Standard Works</h2>AARTS defines hook points, moments in an agent's lifecycle where a security engine can intercept, evaluate, and act. Version 0.1 specifies 19 of them across session management, prompt lifecycle, tool execution, plugin and skill loading, sub-agent behavior, memory operations, and output delivery.Not all hooks carry equal weight. Three illustrate the design logic:<ul type="disc"><li data-list-item-id="e9e499b9374a4cd1f71378518f359c0d6">PreToolUse is the primary checkpoint. Before an agent runs a shell command, writes a file, makes a network request, or installs a package, the security engine sees the action, its arguments, and the context that led to it, then returns a verdict: allow, deny, or ask the user. This is where most real-world threats get caught.</li><li data-list-item-id="ebd37c3ab71aca6ef9cddd1080d793f75">PreLLMRequest operates earlier in the loop, before the prompt reaches the model. It lets engines inspect prompt integrity: whether safety instructions survived context compaction, whether untrusted content was injected into the conversation, whether the instruction layering is intact. If PreToolUse is the checkpoint at the door, PreLLMRequest watches for problems before the agent even decides what to do.</li><li data-list-item-id="ecce291342cb701e4290928d827faf930">PreSkillLoad addresses supply chain risk. When an agent installs a plugin or skill from a marketplace, the engine can evaluate the trust source (where it came from, whether it's signed, whether it was modified) before it gets loaded. AARTS can also direct the host to strip hooks from skills, preventing plugins from disabling the security layer that's supposed to govern them.</li></ul>The remaining 16 hooks follow the same pattern: they sit at the moment where risk becomes real and provide the engine with enough context to make a decision.For those decisions to be portable across hosts, the inputs have to be consistent. AARTS standardizes the event structure: every event carries a mandatory envelope (hook point, session ID, timestamp, host identity) plus standard extensions, reusable field groups for conversation context, tool details, trust source metadata, modification tracking, and provenance. A canonical tool taxonomy maps host-specific tool names (Cursor's "terminal" vs. Claude Code's "bash") to common categories (shell, file_write, web_request, package_install), so detection logic written once works everywhere.Verdicts are structured: a decision (allow, deny, or ask), a threat category, a severity level, confidence, and a human-readable explanation for the user. Two design choices are worth noting. If the host can't prompt the user, ask falls back to deny, safe but a real constraint for headless orchestrators. If the engine crashes or times out, the host treats it as allow and logs the failure. Fail-open is the right default for developer tools where latency matters, but enterprise deployments will want to revisit this per environment.<h2 class="text-align-justify">Conformance Levels: Gradual Adoption</h2>AARTS defines three conformance levels:<ul type="disc"><li data-list-item-id="e18c7418214ef4f97b683f20402deb227">Level 1 (Basic): Requires SessionStart and PreToolUse hooks, minimum tool coverage (shell, file_write, web_request), enforcement of allow and deny (ask may be treated as deny).</li><li data-list-item-id="e0369d9837c299bdfd5a5c490fb899318">Level 2 (Standard): Adds plugin and skill load hooks, prompt lifecycle protection, broader tool coverage, additional hooks (PrePluginLoad, PreSkillLoad, PostInputProcessing, PreLLMRequest, PostToolUse), and requires provenance on PreToolUse.</li><li data-list-item-id="e31f70f735daa583aec2ef8c2d180686d">Level 3 (Comprehensive): Provides full lifecycle coverage including user input, prompt response cycle, tool modification, sub-agents, MCP connect, memory read/write, output delivery, and session end. Clarifies sub-agent inheritance and memory protection.</li></ul>This tiered approach offers a realistic adoption path: Level 1 addresses basic failures, Level 2 tackles prompt integrity and supply chain issues, and Level 3 supports persistent and autonomous agents.<h2 class="text-align-justify">Open&nbsp;Considerations</h2>As we move AARTS beyond a draft specification,&nbsp;the following are being considered:<ul type="disc"><li data-list-item-id="ef56e3529222a5671c75f8e80fbc5c2c9">Enterprise fail-open story: The spec mandates fail-open behavior. Deployment profiles may be needed to reflect the realities of different environments.</li><li data-list-item-id="e5e2beee0ceee16ba315173c83dcc4596">Adapter integrity: Ensuring adapters correctly map tool types and extract artifacts is vital. A conformance test suite for adapters is as important as the specification itself is a next-step priority.</li><li data-list-item-id="eea2912c8ee60ab64a8339e4d3c2b5748">Consent for privacy: Explicit consent is required for external transmission of prompts and tool data. Operational guidance or recommended patterns are needed to avoid incompatible implementations.</li><li data-list-item-id="e7dbd49139e599330dbad43c59209bc82">Ask semantics in headless environments: Treating ask as deny by default is safe but may discourage engines from using ask. A standard way for deployment policy to handle ask in these scenarios is needed.</li></ul>AARTS aims to translate&nbsp;these considerations into predictable operational behavior.<h2 class="text-align-justify">Call for Feedback</h2>AARTS v0.1 is a draft intended for early review by host builders, security vendors, and enterprise operators.&nbsp;The full specification is available <a href="https://github.com/gendigitalinc/aarts" target="_blank">here</a>. If you build agent hosts, consider whether you want every security integration to remain one-off. If you develop security engines, ask yourself whether you want to rewrite the same logic for each host and still miss critical context. AARTS aims to make the answer “no”.&nbsp;We welcome contributions — open an issue or submit a pull request.

AARTS standardizes how AI agent platforms expose security events, enabling portable runtime protection across the growing agent ecosystem

Introducing AARTS: An Open Standard for AI Agent Runtime Safety

You gave an AI agent access to your computer. Maybe it's writing code for you, managing your emails, or handling your finances. It's working with your credentials, acting on your behalf, and making decisions you used to make yourself. Fast, confidently, and largely unsupervised. That's the deal: you trade safety and oversight for productivity. That changes the security model.But who's watching what it actually does?That is why we built the Gen Agent Trust Hub (ATH), our trust layer for the agentic AI ecosystem, designed to secure agents across their lifecycle from skill to runtime to enforcement.Agent Detection and Response (ADR) is the runtime pillar — the layer that governs what agents actually do.<h2 class="text-align-justify">What is ADR?</h2>ADR intercepts agent actions at the moment of execution, before they land, and evaluates whether they're safe. It allows, asks the user, or denies. That's the core.Verification tells you what an agent is. ADR tells you what it's doing. These are complementary. Verification is necessary, but it can't govern what happens at runtime. A verified skill can still hallucinate a malicious package name. A signed plugin can still be exploited through prompt injection. A trusted agent can still lose its safety instructions mid-session and go off the rails. The moment of action is where risk becomes real.The principle isn't new. Every major computing paradigm has developed its own detection and response layer. Endpoints got EDR. Distributed infrastructure got XDR. Not replacements for what came before, but purpose-built layers for new execution surfaces with new threat models. AI agents are the next such surface, and ADR is the layer built for it.Within the Agent Trust Hub, ADR is the enforcement engine that turns trust signals into real-world protection.<h2>Why Now?</h2>The threats targeting AI agents are already here. What follows is a small sample of the agentic threats we’re seeing. The actual attack surface spans everything an agent can do, and agents can do a lot.Your agent installs malware for you. AI agents hallucinate. When they hallucinate a package name during installation, that's not just an error, it's an opportunity. Attackers monitor AI-suggested package names and register them on npm and PyPI, pre-loaded with infostealers and backdoors. The technique is called slopsquatting, and it's already being exploited at scale. In February 2026, researchers uncovered a campaign of&nbsp;<a href="https://www.securityweek.com/new-sandworm_mode-supply-chain-attack-hits-npm/">19 typosquatted packages specifically</a> targeting users of AI coding tools, designed to exfiltrate SSH keys, AWS credentials, and API tokens.Your agent ignores your instructions. Summer Yue, Meta's Director of Alignment, told her OpenClaw agent to&nbsp;<a href="https://techcrunch.com/2026/02/23/a-meta-ai-security-researcher-said-an-openclaw-agent-ran-amok-on-her-inbox/">confirm before taking any action</a> on her email. It worked, until the session ran long enough to trigger context compaction, a mechanism where the agent compresses its memory to keep running. The safety instructions were among the first things dropped. The agent deleted 847 emails. She had to physically run to her machine to stop it.Your agent is a new delivery channel for malware. Attackers are already using multiple paths to get malicious code running through agents. Weaponized skills on public marketplaces have delivered the&nbsp;<a href="https://x.com/GenThreatLabs/status/2018323584834318419">AMOS infostealer to macOS users</a>. Malicious project configurations have achieved&nbsp;<a href="https://research.checkpoint.com/2026/rce-and-api-token-exfiltration-through-claude-code-project-files-cve-2025-59536/">remote code execution in Claude Code</a> the moment a developer opens a repository. Prompt injection through fetched content can turn a trusted agent into an attacker's proxy. The delivery mechanisms vary. The result is the same: your agent executes something it shouldn't, and it does so with your permissions.These are just three examples. The pattern is consistent: agents operate with real authority, and that authority is being exploited. Through supply chains, through the agent's own fragility, and through the same malware ecosystem that has targeted every other computing platform before them.<h2>Where ADR Must Operate</h2>To be effective, ADR must sit as close to the agent's execution loop as possible. Not as an external service watching from the outside. Inside, where the actions happen.Agent sessions contain source code, credentials, business logic, and personal data. ADR evaluates locally, on the device. No prompts, tool inputs, or code leave your machine for analysis.Agents are not robust systems. Their own internal mechanisms can silently drop safety instructions or get poisoned across sessions. A security layer that only sees inputs and outputs misses the moment things go wrong inside. ADR watches the execution loop itself: every action the agent attempts, in context, in sequence.Only a client-side layer sees the complete picture: the prompt history, what files were already modified, the sequence of prior actions. A remote service sees isolated events. ADR sees the session. That difference is what makes it possible to distinguish a legitimate file deletion from a compromised agent cleaning up its tracks.<h2>Sage: ADR in Practice</h2>In February, we&nbsp;<a href="https://www.gendigital.com/blog/news/company-news/sage-ai-agent-security">open-sourced Sage</a> as the first implementation of ADR. It runs client-side, directly inside the agent's execution loop, across Claude Code, Cursor, and OpenClaw. Over 200 detection rules cover supply chain attacks, credential exposure, dangerous commands, persistence mechanisms, and more, backed by Gen's threat intelligence.Since launch,&nbsp;<a href="https://github.com/avast/sage/">Sage</a> has quickly crossed 1,000 installs and is available across the major agentic tool marketplaces. The open-source community is already contributing, porting Sage to new platforms like OpenCode and hardening detection rules. As one independent security researcher concluded after&nbsp;<a href="https://www.linkedin.com/pulse/paranoid-sage-testing-security-tool-agents-radek-hendrych-capff/">testing Sage</a>: "Real-time monitoring and management of AI agents based on deterministic measures is, in my view, the right way to go."All these responses confirm what we suspected: people want this layer.<h2>What's Next</h2>ADR is the runtime layer. But runtime protection alone isn't enough.&nbsp;The Agent Trust Hub is built on the idea that trust in the agentic era must be layered: verification before installation, ecosystem trust signals across marketplaces, and enforcement at execution. ADR closes the gap at the moment risk becomes real.&nbsp;The industry needs a common interface for how agents expose their actions to security tools. A shared standard, so that protection works consistently regardless of which agent you use or which platform you're on. We've been working on that too. More soon.

Inside the Gen Agent Trust Hub, ADR turns trust signals into real-world protection.

Gen Agent Trust Hub Introduces Agent Detection and Response: The Missing Security Layer for Agentic AI 

Threat Research Team

AI agents are starting to do the parts of computing that used to be “hands on keyboard”. They run terminal commands, edit files, install packages, and fetch things from the web, because that’s what it takes to get real work done. Tools like Claude Code, Cursor, and OpenClaw give these agents direct access to your machine and your sensitive information. That's what makes them useful. It's also what makes them risky. These agents make mistakes. They install packages that don't exist because they hallucinated the name. They pick up credentials and pass them where they shouldn't. They'll download and run programs from the internet without a second thought if the task seems to call for it. All of this happens fast, with confidence, and without asking. If you’ve watched an agent confidently suggest curl … | bash or “just add your API key here” into a file it shouldn’t touch, you’ve seen the problem.&nbsp;Agents are also targets. Malicious URLs, poisoned dependencies, and compromised plugins can turn an agent into an attack vector, one that already has access to your files, your terminal, and your network. This is already happening. <a href="https://x.com/GenThreatLabs/status/2018323584834318419" target="_blank" rel="noreferrer noopener">We recently identified</a> around 400 malicious skills on ClawHub, a public registry for agent extensions. At the time of discovery, they accounted for 12% of all available skills. These weren’t obviously shady throwaways; many were weaponized versions of legitimate skills, designed to trick agents into downloading malware.&nbsp;&nbsp;These are the same agents we're starting to trust with payments, infrastructure, and sensitive workflows. The gap between what agents can do and what keeps them in check is real, and it's growing.&nbsp;Today, Gen, the company behind Norton, Avast, LifeLock, and AVG, is releasing Sage to close that gap. With Sage, the Agent Trust Hub now evaluates and governs agent behavior during execution. Not just before installation. Not just at verification. But in the exact moment an action is about to happen.&nbsp;

<h2>What Sage does</h2>Think of Sage as a lightweight safety shield for AI agents. It sits inside the agent's workflow and checks every action before it happens: shell commands, URL fetches, file writes, package installs. For each action, Sage returns a verdict:&nbsp;<ul type="disc"><li data-list-item-id="e2aee30f293d4edf72390d310cdfa3f0e">Allow — no threat detected, the action proceeds&nbsp;</li><li data-list-item-id="e89d49ae9fae752dee97f089112c466b8">Ask — something looks suspicious, the user decides&nbsp;</li><li data-list-item-id="e44ca3f76876a9e666f2544e1233366ba">Deny — confirmed threat, the action is blocked&nbsp;</li></ul>The agent never notices unless something is wrong.&nbsp;Sage catches both sides of the risk. It protects agents from external threats like malicious URLs, compromised packages, and dangerous downloads. And it protects users from agents themselves, when they try to run destructive commands, expose credentials, or write to sensitive system files.&nbsp;Here's a concrete example. An agent automating a setup task decides to download and execute a script from the internet. No review, no confirmation. Sage recognizes the pattern and blocks it before anything runs.&nbsp;<h2 class="text-align-justify">Part of a larger commitment</h2>Sage is not a standalone effort. It’s part of a broader strategy to embed continuous trust into the AI skills ecosystem through the Gen Agent Trust Hub.&nbsp;&nbsp;The Skill Scanner of the <a href="https://ai.gendigital.com/agent-trust-hub" target="_blank" rel="noreferrer noopener">Gen Agent Trust Hub</a> helps determine whether an agent extension is trustworthy before it gets installed, using cloud-based verification and classification. Sage picks up where that leaves off. Once the agent is running, it enforces safety locally, on your machine, checking every action at the moment it's about to execute.&nbsp;&nbsp;Together, they cover the full lifecycle: from the decision to install something to the moment it actually runs. More capabilities are on the way as the agentic ecosystem grows.&nbsp;<h2 class="text-align-justify">Open source, on purpose</h2>The agentic platforms themselves are designed for open integration: open-source tools, community plugins, public hook APIs. A closed security layer would be harder to adopt in a space that moves fast and depends on community integrations.&nbsp;At the same time, there is no established playbook for how to secure AI agents. By open-sourcing Sage, we're proposing one and inviting the community to help define what safe agents should look like in practice.&nbsp;This first version is lightweight. It's not a full antivirus product as we know it, but it addresses the problems where they are. It covers the high-risk paths we think matter most: commands, file changes, URL fetches, and package installs, including catching hallucinated or malicious dependencies before they land on your machine. Sage ships with over 200 detection rules covering command injection, persistence, credential exposure, obfuscation, and supply-chain attacks.&nbsp;Sage currently supports Claude Code, Cursor, and OpenClaw, with more platforms on the way. If you find a detection that's too noisy or not strict enough, open an issue. If you want to add a rule, improve a check, or add support for another agent platform, send a pull request.&nbsp;We built Sage to be extended.&nbsp;&nbsp;<h2>Try it</h2>Learn more about Sage at <a href="https://ai.gendigital.com/sage" target="_blank" rel="noreferrer noopener">https://ai.gendigital.com/sage</a>. For technical details, documentation, and source code, visit the project on <a href="https://github.com/avast/sage" target="_blank" rel="noreferrer noopener">https://github.com/avast/sage.</a>&nbsp;If you use Claude Code, Cursor, or OpenClaw, install Sage and put it in the path of real work. The fastest way to improve a safety layer is to expose it to real commands, real repos, and real mistakes. That's what we're doing here — shipping early, in the open.&nbsp;

Shubh Jagani

Posts by Shubh Jagani

Gen Launches AI Data Checker as Part of Its Agent Trust Hub