Director of Threat Research & Applied AI

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

Security Evangelist at Gen

Company News

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 

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;

Closing the growing security gap between what Al agents can do and what keeps them in check

Introducing Sage: Safety for Agents 

AI agents aren’t just helpful in chats anymore. They’re actually taking action on your behalf. Autonomous AI can access data. They move from suggestion to execution without hesitation.&nbsp;This is what we call “mindless artificial intelligence.”&nbsp;When technology starts taking action on our behalf, trust has to be built into the system itself.&nbsp;That’s why Gen is partnering with Vercel to bring independent safety verification to the AI skills ecosystem at <a href="https://skills.sh/" target="_blank">skills.sh</a>, embedding trust directly into the skills layer.&nbsp;

<h2>Independent verification. Built in.&nbsp;</h2>Through this partnership, the Gen <a href="https://ai.gendigital.com/agent-trust-hub" target="_blank">Agent Trust Hub</a> will evaluate skills on skills.sh and assign clear, transparent classifications:&nbsp;🟢 Safe&nbsp; 🟡 Low Risk&nbsp; 🟠 High Risk&nbsp; 🔴 Critical Risk&nbsp;Behind those ratings is advanced risk modeling and threat intelligence from Gen Threat Labs, analyzing permissions, behaviors, vulnerabilities and potential malicious intent.&nbsp;The goal isn’t to slow innovation. It’s to help it scale responsibly. Developers should be able to build boldly. Users should be able to install confidently. And both deserve clarity.&nbsp;<h2>Security as infrastructure, not an afterthought&nbsp;</h2>By integrating verification directly into skills.sh, Gen and Vercel are making security part of the AI development lifecycle, not something bolted on after the fact.&nbsp;In the agentic world, skills are how things get done. Until now, developers and users had limited visibility into whether a skill was truly safe. Reputation and documentation can’t tell the whole story. As agents gain autonomy, guesswork isn’t good enough.&nbsp;The trust has to be visible.

<h2>Powering Digital Freedom in what comes next&nbsp;</h2>At Gen, we believe Digital Freedom means being able to embrace new technology without sacrificing safety or confidence. As AI evolves, our responsibility evolves with it.&nbsp;The future of AI will be powerful. And expansive. But, it must also be secure by design.&nbsp;This partnership is one more step toward building the trust foundation the agentic era demands, so innovation and confidence can grow together.&nbsp;

Jakub Křoustek

Posts by Jakub Křoustek

Introducing AARTS: An Open Standard for AI Agent Runtime Safety

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