Tag: threat detection and response

Package Hack Wake-Up Call: My Playbook for Securing Cowork, Coding Agents, and Secrets

I love being a builder. It feels like a superpower I can’t stop using, and lately I’ve been channeling it into better workflows, faster experimentation, and sharper product thinking.

I tinker with my Claude Code workflows to make every day more effortless. I’m having a blast creating AI-generated interview snapshots and opportunity solution trees for Vistaly. I also spend time digging into traces and iterating on the AI coaches I use for our discovery courses.

Then the recent wave of malicious software spreading through the open-source community popped my bubble. It hit companies big and small—names like OpenAI, PostHog, and Zapier. As I dug in, I realized what many cybersecurity experts have long known: this is a deep rabbit hole. If I want to build responsibly, I have to get significantly better at protecting my devices, credentials, and code. And if you’re building with AI or modern tooling, you likely do, too.

Here’s why. We all rely on open-source software. Most modern applications assemble tried-and-true components—parsing a PDF, handling dates across time zones, visualizing spreadsheet data, connecting to an API—rather than reinventing them. The same is true for agent skills and MCP servers; they accelerate how we get value from models. This is overwhelmingly a good thing. But it also creates an attack surface that bad actors exploit.

We don’t need to abandon third-party code. We do need to understand the mechanisms attackers use and consistently defend against them.

When one malicious worm compromises hundreds of packages, what should dev teams do? This visual teaser maps the agenda—how it spreads, how to guard against it, AI tool risks, and concrete steps to mitigate.

On May 11th, I started seeing tweets about a TanStack hack. At that time, I didn’t know what TanStack was. But apparently, it’s a popular set of JavaScript libraries that are used by a lot of React sites. At first, I didn’t pay much attention. Then I learned the packages were compromised by a worm—malicious software that self-replicates—and it spread quickly. Within hours, dozens of packages were implicated; by day’s end, it was in the hundreds. That’s when I knew I had to lean in.

If you’ve explored safe development practices with coding agents before, you’ve seen the basics of package safety. A package is a bundle of reusable code shared through registries, and nearly every app you use depends on them. The unfortunate twist with this specific hack, known as the Mini Shai-Hulud worm, is that it shows prior “safe enough” heuristics aren’t sufficient. Popularity and trust signals don’t guarantee safety. We have to do more.

So here’s what I’ll cover today: how malicious software typically works, a practical framework for guarding against it, the specific risks of using Cowork to write and run code, and concrete steps to mitigate that risk. My goal is simple: help you keep building—despite the risks—while protecting your data and your business.

Quick disclaimer: I’m not a security expert. I’m sharing my personal journey and what I’ve learned through research and hands-on work. Please use your best judgment when applying any of this.

Package hacks share a simple playbook: get in, sweep for secrets, and phone home. This visual breaks down the 3 steps and flags new entry points—from packages to MCP servers, agent skills, and app extensions.

An agent recently scoured over 230,000 malicious software incidents and found that most malicious software follows a similar pattern. First, it needs an entry point onto your computer. Once installed, it scours your device for sensitive data, and then it uses your network connection to send that data to its own servers. The Mini Shai-Hulud worm spreads via malicious package install scripts that run at download time, then searches the device for credentials (including package publishing rights), poisons additional packages to continue replicating, and uses multiple channels—including the victim’s own GitHub public repos—to distribute secrets.

In practice, most attacks boil down to three steps: 1) It finds an entry point to your device. 2) It searches your device for sensitive data. 3) It sends that data to its own server. The good news: this pattern also tells us how to defend. We can harden entry points, minimize what code and agents can access, and constrain outgoing network traffic.

Keep in mind that install scripts aren’t the only entry vector. Any code that runs on your machine could contain malicious payloads: third-party packages, agent skills, MCP servers, browser or desktop extensions—the list is long. As coding agents and “vibe coding” tools become mainstream, more non-engineers are exposed to the same risks engineers have managed for years.

You might be at elevated risk if you do any of the following: you download and use third-party skills or MCP servers; you let Claude Code, Codex, or other coding agents write scripts that run locally and use third-party packages; you use an IDE like VS Code or Cursor with third-party extensions; or you install third-party extensions in tools like Obsidian. This isn’t an exhaustive list, but if any of these apply, it’s worth tightening your approach.

Relying on third-party code? This visual highlights four common risk zones—agent skills/MCP servers, coding agents, IDE extensions, and Obsidian plugins—and urges a review of downloads, local scripts, and add-ons.

The “safest” approach would be to avoid installing third-party software on your local device entirely. That’s not realistic. We all depend on third-party components in our stack. So I’ll start with one of the most common paths for non-engineers writing and running code today: Cowork.

Evaluating Cowork’s safety was eye-opening. Cowork offers meaningful protection—more than running code directly on your machine—but it isn’t bulletproof. There’s a notable gap you should understand.

Here’s how Cowork helps. It runs code inside a virtual machine, which isolates the execution environment from your real device—a quarantine room for code. While Cowork doesn’t fully control what comes into the room (that part is on you), if malicious code gets in, it’s contained and cannot reach the rest of your filesystem. Cowork also limits outbound network traffic from the virtual machine, which helps disrupt data exfiltration. However, it’s not foolproof.

Because Claude can install packages inside Cowork, it remains susceptible to malicious code like the Mini Shai-Hulud worm. And GitHub is on the allow list so Cowork can read and write to your repos. Since the Mini Shai-Hulud worm uses GitHub to publish secrets, this creates exposure. The crucial mitigation: if you never give Cowork access to sensitive data, there’s nothing for an attacker to steal.

A quick visual from a security deep dive on package hacks shows how Cowork handles threats: entry points are contained, data is only safe when kept outside, and network traffic is partly limited—making shared data the gap to watch.

Your responsibility is straightforward but critical: your data is only safe if it stays outside the virtual machine. When you mount folders into Cowork, those folders become accessible to any code running inside the VM. That includes malicious scripts. Before sharing, ask two questions: do the folders contain any credentials or secrets, and do they include proprietary data that would be harmful if accessed?

It’s common for code to need credentials. That’s why Cowork includes connectors to third-party sources like Google Drive and Slack. Credentials configured for these connectors never enter the VM—they remain outside the quarantine room—so they’re not exposed to malicious code. But if your code requires additional credentials inside the VM, scope them tightly and assume they could be compromised.

You can also use custom MCP servers you create yourself with Cowork. Those credentials stay outside the VM as well, provided the MCP servers are remote (hosted on a web server, not downloaded locally). It’s more work than dropping in a local server, but it keeps secrets out of reach from VM-executed code.

Beyond credentials, scrutinize the actual content you share with Cowork, including anything accessed through connectors. Least privilege is the rule: grant only what’s absolutely necessary for the task, and nothing more.

Amid a wave of package-supply attacks, this Product Talk visual launches a 3-part guide to safer AI building—starting with Cowork safety today, then Claude code config next week, and off-device development coming soon.

What about skills? Cowork supports skills, and you can add third-party skills inside the quarantine room. If you’re not placing your own data in that room, you can afford more risk. The moment you add sensitive or proprietary data, be selective. Skills can include third-party code, and bad actors use skill directories to distribute malicious payloads. Personally, I never use third-party skills as-is. If one looks useful, I read through the files, then ask Claude to recreate it so I understand what it does and maintain control. If I were to use third-party skills, I’d do it in Cowork and keep their data access to the minimum necessary.

Overall, Cowork is a solid, “safe-ish” option if you’re disciplined about what you share. The challenge is that utility often requires access to real data—exactly what we’re trying to protect. In an upcoming deep dive, I’ll outline strategies to keep malicious code out in the first place. While I’ll focus on local development, the same patterns can extend to Cowork with a bit of setup.

One more important clarification: don’t confuse Cowork with the Code tab in the Claude Desktop app. Cowork runs code inside a virtual machine. The Code tab does not. If you ask Claude to write and execute code from the Code tab, that code runs on your local device and you’re fully responsible for security. There is one exception: the Code tab can run code in Anthropic’s cloud; I’ll cover that approach when we get into moving development off the local machine.

To summarize Cowork’s protections against the attacker’s three-step pattern: installs and scripts still run, but they’re contained inside an isolated virtual machine instead of your real device; access to sensitive data is strongly limited to the specific folders you mount, leaving the rest of your filesystem (including unrelated credentials) out of reach; data exfiltration is partially constrained because Anthropic limits outbound network traffic from the VM—helpful, but not absolute. By contrast, local Code tab sessions offer no isolation, no filesystem restrictions, and no network limits—so any malicious install scripts run directly on your machine with full access and open egress.

My takeaways so far: I still love building with AI, but I’m doing it more cautiously. Cowork offers meaningful containment when used deliberately. I still prefer the flexibility of Claude Code, and I’ve reconfigured my setup to reduce risk. Even so, “safer” isn’t “safe,” which is why I’m increasingly shifting development off my local device to more controlled environments. I’ll share the practical details—tools, configs, and scripts—in the next installments.

If this perspective is useful, let me know. I want builders to move fast—and safely—through this new era of agentic AI. Until then, stay safe out there.

Inspired by this post on Product Talk.

June 3, 2026
AI Data Security for Product Teams: Protect Sensitive Product Data Without Slowing Innovation

Protecting product data has never felt more urgent. Every week, my teams experiment with gen ai prototypes and LLM-powered capabilities, and I’m accountable for ensuring our innovation never compromises cybersecurity, privacy, or customer trust. The goal is not to slow down—it's to build in the right guardrails so speed and safety reinforce each other.

Understand AI data security risks in product teams, what product data is most exposed, and how to use AI tools responsibly without slowing innovation.

When I assess AI risk with product managers, I start with how data moves. The biggest threats usually come from prompt and context leaks, unsafe logging of sensitive inputs or outputs, permissive access controls, unmanaged third-party model usage (shadow AI), and unclear data-retention policies. For LLMs for product managers, I emphasize that every step in AI workflows—from collection to processing to storage—must assume adversarial conditions.

In my experience, the product data most exposed includes customer PII and payment identifiers, internal strategy documents and roadmaps, analytics and behavioral telemetry tied to users, feature flags and configuration values, embeddings and vector stores that can reveal sensitive patterns, and the prompts or contexts themselves. Even “harmless” evaluation datasets can contain inferred identities. Treat all of this as high-value assets in your data governance model.

I apply privacy-by-design from the first discovery conversation: minimize data by default, redact or tokenize before any external model call, and separate identities from content wherever possible. A retrieval-first pipeline helps keep raw customer data within our boundary while still enabling relevant context. We combine deterministic safeguards (policy-based redaction, allow/deny lists) with runtime observability to detect anomalous prompts, outputs, or access patterns.

To keep velocity high, we operationalize risk rather than debate it ad hoc. A lightweight risk scoring rubric classifies each capability (e.g., internal-only, customer-facing, regulated data adjacent) and dictates controls: redaction requirements, human-in-the-loop thresholds, eval-driven development gates, and incident response readiness. These controls live in CI/CD so product teams get fast, automated feedback without waiting on meetings.

Partnership is essential. I bring Security, Legal, and Data partners into the product trios early to align on regulatory compliance and threat modeling while scoping solutions that meet outcome goals. We maintain a shared catalog of approved providers and architectures, document data flows, and version our policies just like code—so everyone can see what changed and why.

Vendor diligence is non-negotiable. I ask LLM providers about data retention and training usage, encryption at rest and in transit, key management, regional data controls, audit posture (SOC 2, ISO 27001, HIPAA where needed), and support for private networking. We restrict scopes with least-privilege access and instrument robust observability for threat detection and response across the full path, not just the API call.

Culture makes the biggest difference. I coach teams on prompt hygiene, secret handling, and context window management; we publish redaction patterns, approved libraries, and clear do/don’t examples. When incidents happen, we treat them as learning opportunities, run blameless reviews, and update our playbooks, guardrails, and training materials accordingly.

The outcome I aim for is confidence with speed: we ship AI features that customers love while protecting the data they entrust to us. With a clear risk model, strong data governance, and embedded controls, product teams can innovate boldly—without compromising on security or trust.

Inspired by this post on Product School.

April 27, 2026
Inside Artemis’ AI vs AI Security War: Hiring at Speed, PMF Signals, and Founder-Led Sales

I’m fascinated by how fast truly AI-native companies can move when the problem is urgent, the founders have deep domain credibility, and the culture is built around customer obsession from day one. Artemis, an AI-native security platform, just emerged from stealth with $70M in combined seed and Series A funding, assembled a 30-person team in seven months, and made a bold promise to “stay on a texting basis with every customer, even at scale.” As a product leader, I see this as a masterclass in AI Strategy, go-to-market focus, and disciplined execution in cybersecurity.

At its core, Artemis is operating in what I’d call an “AI vs AI” security war: increasingly, we’re defending against adversaries who leverage models just as aggressively as we do. That shifts the job from rule-writing to intelligence orchestration, threat detection and response at machine speed, and continuous evaluation. It also explains why AI-native companies are outperforming their AI-enabled counterparts—when intelligence is the product, the org must be built around model quality, data pipelines, and rapid iteration, not as a bolt-on.

Founder-market fit is the early signal I look for, and here it’s unmistakable. Shachar Hirshberg’s “AWS and Palo Alto” playbook and Dan Shiebler’s path “From Twitter to Abnormal” create a rare combination: deep infrastructure and enterprise security know-how paired with production-grade machine learning at scale. When those experiences intersect, you get crisp problem statements, faster learning loops, and credibility with the exact ICP that feels the pain first.

Timing the leap to build is more art than science, but I listen for three cues: customers describing the problem in quantified terms, a wedge that can deliver value within one buying cycle, and a data advantage that compounds. Artemis clearly identified a high-urgency buyer and ignored adjacent segments that would dilute focus—an underrated act of courage that accelerates product-market fit.

Hiring for AI fluency is a different exercise than traditional software roles. I don’t just screen for model familiarity; I screen for product thinking under uncertainty, a bias for eval-driven development, and the ability to explain tradeoffs to security teams. Practical prompts help: “How would you diagnose precision/recall tradeoffs under evolving threat patterns?” or “Show me how you’d design a red/blue evaluation harness for a new detection.” The best candidates can translate model metrics into business outcomes and customer trust.

Building a 30-person AI-native team in stealth requires ruthless clarity on the handful of roles that compound: forward deployed engineers who can ship with customers, solutions engineering that feeds learning back into the model, and product managers who treat data as the primary surface area. Culture-wise, I anchor on two rituals: weekly customer debriefs with actual artifacts (alerts, misclassifications, escalations) and a written log of hypotheses, evals, and next bets—so the entire team can reason from the same evidence.

AI implementation reshapes the dashboard. Beyond the usual business KPIs, I watch a second layer: model precision/recall by scenario, alert fatigue reduction, time-to-first-signal on emerging threats, drift and data freshness, and latency under load. When these improve, downstream product metrics—activation, expansion, NRR—almost always follow. Observability isn’t an afterthought; it’s the control center for trust in AI-driven cybersecurity.

ICP discipline is non-negotiable. Artemis focused on the segment with the highest urgency-to-adopt and the clearest data pathways, and deliberately ignored a seemingly attractive adjacent ICP that would slow learning. I’ve made that trade myself: it feels painful in the short term but pays off in faster cycles, cleaner roadmap decisions, and better founder-led GTM.

Closing the first customers is where the magic happens—and where the most surprising signals of early product-market fit emerge. It’s rarely about feature breadth. It’s about whether customers escalate, volunteer data, and invite your team into their workflows. In founder-led sales, the most valuable insights come from the objections you lose on. I document every “no,” cluster them by root cause, and turn the top two into experiments within a sprint.

I also believe the first product should make founders a little uncomfortable—just enough to prove the thesis in the messiest, fastest path possible. In AI security, that often means prioritizing the smallest end-to-end loop that can stop or downgrade a real threat, even if the initial UX is rough. If the loop works, you’ll earn the right to harden it.

Co-founder dynamics matter as much as the roadmap. I liked the question “Should we be arguing more?” because it reframes conflict as a system. My rule: disagree in writing with a time box, escalate only the principle in dispute (not the plan), and commit to the decision with a pre-agreed review point. This keeps speed without calcifying bad calls.

On structure, I’m convinced AI-native beats AI-enabled for this market. Organize around data, evaluations, and deployment rather than traditional feature teams. Blend product, research, and solutions into durable, customer-facing units. Consider forward deployed engineers who can ship safely in live environments and bring back the sharpest, most actionable learning. It’s the only way to keep pace with adversaries that iterate as fast as you do.

The broader landscape provides context and competition. I benchmark capabilities and go-to-market motions against players like Abnormal, CrowdStrike, and Palo Alto Networks, with respect for the automation lineage from Demisto (now Cortex XSOAR). Cloud scale and data gravity from Amazon Web Services (AWS) matter, while model innovations from OpenAI and Anthropic raise the offensive and defensive bar. And Artemis is staking a claim in that intersection—where security outcomes, model excellence, and frontline customer intimacy meet.

If you care about AI risk management, threat detection and response, and building empowered product teams that can win in this “AI vs AI” environment, the lessons here are clear: hire for AI fluency, not just titles; instrument the model like a business; let founder-led GTM shape your roadmap; and keep the customer close enough that you can text them—because that’s how you outlearn the market.

April 21, 2026
Behavioral Analytics That Crush Fraud: Spot Anomalies, Prioritize Risk, Act with Confidence

Fraud teams are drowning in signals—events, alerts, and edge cases that look suspicious but rarely point to what truly matters now. In my role leading product, I focus on turning that noise into clear, ranked actions the team can trust. Behavioral analytics is how we bridge the gap from “something looks off” to “here’s why it matters and what to do next.”

See how behavioral analytics helps fraud management teams surface anomalies, prioritize risk factors, and act faster with greater confidence.

When I build fraud capabilities, I start by defining the outcomes that matter: find anomalies early, prioritize by impact, and respond in minutes—not days. That requires a rigorous approach to data governance, strong observability across the stack, and a mindset tuned to threat detection and response rather than passive reporting.

For me, behavioral analytics means unifying event streams across web, mobile, payments, and support into a single, trustworthy, unified analytics platform. We then apply anomaly detection on top of baselines for user, device, and entity behavior—capturing velocity spikes, geolocation drift, account takeover signals, and unusual journey paths. The win is not more alerts; it’s clearer context per alert.

Prioritization is where the value compounds. I combine deterministic signals (e.g., device fingerprint mismatches, impossible travel, repeated declines) with weighted risk scoring that adapts to emerging patterns. This helps fraud analysts triage by potential loss and customer impact, not just alert volume—so the highest-risk cases land at the top of the queue with the right context attached.

Actionability is the final mile. I map each risk tier to a playbook—step-up authentication, temporary holds, secondary review, or immediate block—so teams can act with confidence. Real-time alerts route to the right channel; feature flags allow fast containment; and AI risk management practices ensure continuous learning while preserving precision and recall. We close the loop by measuring investigation time, false positive rates, and recovery to keep improving.

A few lessons keep paying off: instrument early and consistently; keep your schema stable; document risk definitions; and test changes with A/B testing to quantify impact before scaling. Treat your fraud stack like a mission-critical cybersecurity system with tight SLAs, clear ownership, and auditable decisions—because it is.

If you’re evaluating your next move, start with a narrow but high-ROI use case (account takeover or payment fraud), stand up clear dashboards for analysts, and iterate on the risk scoring model weekly. With disciplined data practices and aligned playbooks, behavioral analytics turns scattered signals into decisive, defensible action.

Inspired by this post on Amplitude – Perspectives.

March 5, 2026
3 Powerful Ways AI Is Rewriting Cybersecurity: Smarter Defense, Faster Response, Fewer Breaches

Every week, I watch the cybersecurity landscape shift under our feet. As a VP of Product Management, I’m responsible for building secure, resilient products—and that means understanding how artificial intelligence is transforming the way IT teams defend, respond, and even anticipate attacks.

Learn the ways in which AI is transforming both cybersecurity offense and defense for IT teams.

First, AI supercharges threat detection and prevention. Pattern-recognition models now sift through endpoint telemetry, identity signals, and network flows to surface anomalies in near real time. In practice, that means fewer false positives, faster prioritization, and earlier containment. We’re pairing behavioral analytics with enrichment from our SIEM/EDR stack so analysts get a ranked, explainable view of risk instead of a noisy alert queue—directly improving mean time to detect and laying the groundwork for scalable threat detection and response.

Second, AI accelerates incident response. We’ve embedded LLM-powered copilots into our SOC workflows to summarize alerts, propose next-best actions, and auto-generate draft remediation steps from playbooks. Orchestration then executes routine tasks—isolating endpoints, rotating credentials, updating tickets—while keeping a human-in-the-loop for approvals. To keep this safe, we use privacy-by-design principles, a retrieval-first pipeline for authoritative playbook content, and eval-driven development to measure precision/recall on suggested actions. The result is meaningful reduction in mean time to recover and more consistent incident management.

Third, the offense is getting smarter—and we need to be honest about it. Adversaries use gen AI to craft targeted spear-phishing, deepfake executive voice notes, and polymorphic malware that evades signature-based tools. We counter by red-teaming with AI, deploying deception tech to waste attacker cycles, and hardening identity as the new perimeter (MFA, conditional access, continuous risk scoring). Education matters, too: when employees see how convincing AI-generated lures have become, phishing reports spike and successful compromise rates drop.

None of this works without strong governance. We treat AI like any high-impact capability: rigorous data governance, model access controls, and AI risk management across the lifecycle. We log model prompts and outputs, restrict sensitive data via contextual policies, and continuously test for drift and bias. This is as much an IT leadership challenge as it is a technical one—clear ownership, well-defined runbooks, and regular tabletop exercises make the difference between resilience and chaos.

If you’re getting started, I recommend a focused 90-day plan: identify one high-signal detection use case, one response playbook ripe for automation, and one employee risk area (usually phishing) for immediate uplift. Instrument everything—latency, precision/recall, MTTR—and iterate with a cross-functional group spanning security engineering, SRE, and product management leadership. With disciplined AI strategy and guardrails in place, you can move faster, reduce noise, and stay ahead of adversaries without compromising data or trust.

Inspired by this post on Pendo – Perspectives.

January 4, 2026
4 Critical AI Risks Every CIO Must Tackle Now—and a Practical Playbook to Mitigate Them

I spend a lot of time with CIOs and IT leaders who are moving fast on generative AI. The momentum is real, but so are the risks. When AI touches core workflows, data, and customer experiences, we need a clear, pragmatic plan that blends AI Strategy with disciplined product management leadership and IT governance.

Learn about the risks that AI poses to IT teams, and how they can mitigate them.

Here are the four risks I see most often—and the playbook I use to de-risk delivery while preserving speed and innovation.

Risk #1: Shadow AI and data leakage. Teams experiment with unapproved tools, and sensitive data ends up in prompts, logs, or third-party services. Without strong data governance and privacy-by-design, even a small proof of concept can create outsized exposure.

How I mitigate it: start with an AI acceptable-use policy, data classification, and clear guardrails on what can be prompted. Deploy a redaction layer and secrets management before any model call. Favor a retrieval-first pipeline so models reason over vetted internal knowledge rather than raw or personal data. Conduct vendor due diligence and DPAs up front, and centralize audit logs to support regulatory compliance and incident response.

Risk #2: Hallucinations and unreliable outputs. LLMs are probabilistic; they can fabricate citations, numbers, or steps. In customer support and internal operations, this erodes trust and creates rework—especially when teams assume model answers are authoritative.

How I mitigate it: adopt eval-driven development with task-specific test sets, reference answers, and pass/fail thresholds that gate CI/CD. Ground models with retrieval, constrain outputs with schemas, and keep a human-in-the-loop for high-risk actions. A/B testing, error taxonomies, and continuous monitoring turn model behavior into measurable, improvable Web Vitals for AI reliability.

Risk #3: Expanded attack surface. Prompt injection, data exfiltration, supply chain risks in model providers, and insecure connectors can undermine existing cybersecurity controls. Traditional threat models often miss these new interaction patterns.

How I mitigate it: treat AI as a first-class asset in threat detection and response. Implement input/output filtering, allow/deny lists, content moderation, and strict isolation of tools and connectors. Red team prompts and tools regularly, rotate credentials, and codify runbooks with SRE and incident management for fast containment. Apply least privilege to agents, APIs, and vector stores, and monitor for anomalous tool-use.

Risk #4: Compliance, bias, and auditability gaps. As AI scales, questions about explainability, fairness, data residency, and retention move from theoretical to board-level. Without traceability, it’s hard to satisfy audits or respond to regulators.

How I mitigate it: embed privacy-by-design from the first sprint—data minimization, consent, purpose limitation, and retention controls. Maintain model cards, versioning, and lineage for prompts, datasets, and parameters. Centralize audit logs, set policies for high-risk use cases, and run periodic compliance reviews with security and legal. Cross-functional communities of practice keep changes aligned across product, engineering, and IT Leadership.

Operationally, I anchor AI initiatives to outcomes vs output OKRs, use empowered product teams and product trios to balance feasibility, value, and risk, and integrate model changes into CI/CD with quality gates. This creates a repeatable mechanism to ship safely, learn quickly, and scale what works.

If you’re standing up new AI workflows or hardening what you already have in production, this playbook gives you a practical path: drive adoption confidently, protect your data, and stay compliant while maintaining competitive velocity.

The bottom line: AI risk management isn’t a brake on innovation—it’s how we earn the right to go faster.

Inspired by this post on Pendo – Perspectives.

January 3, 2026
AIUC-1 Certified: How Intercom Raises the Bar for Trustworthy, Enterprise-Ready AI Agents

I build products on the belief that trust is earned in every design decision and every deployment. Trust has always been a first principle at Intercom, from our early investments in security and privacy to the globally recognized certifications that shape our approach today.

As AI becomes more deeply embedded in customer-facing work, it’s essential that businesses can rely on systems that are safe, reliable, and governed to the highest standards. That’s why we’re proud to share that Intercom is now AIUC-1 certified, becoming one of the first companies to meet the world’s first standard designed specifically for AI Agents. For leaders navigating AI Strategy and AI risk management, this is more than a badge—it’s a measurable leap forward in governance and operational rigor.

AIUC-1 is the first certification tailored to the unique risks and challenges of AI Agents. It complements broader AI governance frameworks like ISO 42001 by focusing on enterprise-specific concerns like security, customer safety, system reliability, data and privacy, society, and accountability. In practice, this alignment helps us translate policy into deployable safeguards across cybersecurity, data governance, and regulatory compliance.

To achieve certification, organizations undergo independent third-party audits and quarterly adversarial testing across more than a thousand enterprise risk scenarios. This continuous technical evaluation ensures that AI systems remain robust against fast-evolving threats and that safeguards keep pace with rapid progress in the field. As a product leader, I welcome this level of scrutiny—it’s how we operationalize threat detection and response and make agentic AI dependable at scale.

AIUC-1 itself evolves every quarter, incorporating new research, threat patterns, and global best practices. The standard is shaped by the AIUC-1 Consortium, launched in November with more than 50 founding members who collectively handle tens of trillions of dollars in payments and serve over a billion people daily. Intercom is proud not only to be certified, but to be recognized as a founding technical contributor helping shape the development of the standard. That continuous, community-driven iteration mirrors how we build—measure, learn, and harden—so our customers benefit from real-world, enterprise-ready AI.

Intercom has decades of combined experience in security, compliance, and trust, and we’ve consistently demonstrated that robust governance and fast innovation can coexist. Achieving AIUC-1 certification reinforces that the same rigor we apply across our platform also extends to Fin, our AI Agent. I’ve seen first-hand how risk and procurement teams evaluate generative AI: they expect clarity, evidence, and controls. This certification delivers independent proof that our approach meets those expectations.

For our customers, this certification provides independent validation that Intercom’s AI systems are safe, resilient, and enterprise-ready. It confirms that our AI is tested regularly, built with strong safeguards, and aligned with the expectations of modern security and risk teams. It also signals our continued leadership in shaping responsible AI practices globally, ensuring our customers benefit from standards built for real-world use. In short, you can move faster with confidence—without compromising on governance.

Intercom has always approached trust as an ongoing commitment. AIUC-1 strengthens the foundation we’ve built across other frameworks and certifications, including SOC 2, ISO 27001, ISO 27701, ISO 27018, HIPAA, HDS, and ISO 42001. Together, these certifications create a comprehensive control fabric across privacy, security, and reliability—critical pillars for any enterprise deploying gen AI into production workflows.

As AI technology accelerates, we will continue to evolve our safeguards, deepen our governance practices, and contribute to the standards that shape responsible AI. Our promise is simple: to build AI that is not only powerful and efficient, but safe, transparent, and deserving of the trust our customers place in us. That’s how we turn innovation into durable value.

You can learn more about our certifications and access our security and compliance documentation through the Intercom Trust Center.

Get started with Fin and see how an AIUC-1 certified, enterprise-ready AI Agent can elevate your customer experience with confidence.

Inspired by this post on The Intercom Blog.

December 8, 2025
Mastering Data Governance in the AI Era: Move Fast, Reduce Risk, and Unlock Trusted Insights

Every week, I’m in conversations with product leaders, engineers, and security teams who are trying to ship AI features faster without compromising trust. The tension is real: stakeholders want velocity, customers want transparency, and regulators want accountability. That’s exactly where modern data governance earns its keep.

New AI pressures are redefining what good governance takes. Learn how to build better frameworks, move fast with confidence, and keep your data from being a black box.

In my role leading product management, I’ve learned that robust data governance isn’t a compliance checkbox—it’s a strategic capability. When we treat governance as a product, we architect for clarity, safety, and speed. That means aligning AI Strategy with day-to-day delivery so teams know what they can ship, when, and why.

Here’s the practical blueprint I rely on. First, establish ownership and a shared language. Create a living data catalog, lineage maps, and clear data classifications so teams know which assets are sensitive, regulated, or eligible for training LLMs. Second, harden privacy-by-design and least-privilege access. Bake PII detection, secrets management, and role-based policies directly into your workflows. Third, bring quality and observability to the forefront: instrument data contracts, monitor drift, and track model performance across environments. Finally, implement model governance end to end—dataset cards, model cards, bias testing, human-in-the-loop review, and a repeatable evaluation harness.

To move fast with confidence, make governance invisible and automated. Treat policies as code in CI/CD, gate deployments with pre-merge checks, and fail builds that violate data contracts. Log prompts and outputs responsibly, route unsafe patterns to red-teaming, and use a retrieval-first pipeline to anchor models on verified sources rather than fragile context stuffing. This is how we scale AI product development while keeping audit trails complete and costs in check.

Avoiding the black-box problem starts with transparency. Document assumptions, training data sources, and known limitations—then expose explanations where it matters in the product experience. Pair this with a unified analytics platform to tie telemetry, feature flags, and user feedback to model changes. When something goes sideways, your observability, incident management playbooks, and threat detection and response processes should make root-cause analysis fast and defensible.

If you’re building your program from scratch, use a 30-60-90 approach. In the first 30 days, inventory systems, classify data, and map high-risk use cases. By day 60, formalize RACI for governance, deploy access controls, and set up your evaluation pipeline with golden datasets and measurable acceptance thresholds. By day 90, operationalize incident response, conduct tabletop exercises, and wire governance outcomes into OKRs—think time-to-approval for high-risk changes, reduction in production incidents, and model evaluation pass rates.

This playbook pays off in board conversations and with customers. You can articulate your AI risk management posture, show measurable progress on regulatory compliance, and demonstrate how governance accelerates—not hinders—delivery. Most importantly, your teams gain the confidence to experiment, knowing there’s a safety net that protects users, the brand, and the business.

If your organization is wrestling with how to balance innovation and control, start small, codify what works, and scale with intent. With the right foundations in data governance, AI becomes an engine for durable advantage—not a source of sleepless nights.

Inspired by this post on Amplitude – Perspectives.

November 21, 2025
How Incident.io’s AI SRE Diagnoses, Hypothesizes, and Fixes Outages in Slack at Record Speed

When your site goes down, every second counts. I’ve lived that reality across multiple product lines, and the difference between a five-minute blip and a two-hour outage is felt by customers, engineers, and the business. That’s why I’ve been closely following how Incident.io has evolved from coordination during chaos to intelligent, proactive response.

Now, they’re building something new: an AI SRE that can actually help diagnose and respond to incidents. As someone who thinks deeply about reliability, velocity, and customer trust, that promise hits the intersection of AI Strategy, product management leadership, and operational excellence.

I recently spent time with Lawrence Jones, Founding Engineer at Incident.io and Ed Dean Product Lead for AI at Incident.io, digging into how their team is teaching AI to think like a site reliability engineer. They shared how they went from simple prototypes that summarized incidents to a multi-agent system that forms hypotheses, tests them, and even drafts fixes—all from within Slack.

Here’s what stood out to me first: AI’s biggest impact comes from compressing time—identifying causes minutes instead of hours. In practice, that means fewer cycles lost to paging the wrong on-call, clearer paths to root cause, and faster recovery—without cutting humans out of the decision loop.

Equally important is deciding where automation belongs. The team’s approach aligns with how I evaluate high-risk workflows: Identify which parts of debugging can safely be automated. Combine retrieval, tagging, and re-ranking to find relevant context fast. Use post-incident “time travel” evals to measure how well their AI performed. Balance human trust and AI confidence inside high-stakes workflows. The human remains accountable; the AI accelerates context, options, and execution.

On the technical side, the retrieval choices were refreshingly pragmatic. Retrieval-augmented reasoning still benefits from simplicity: deterministic tagging and re-ranking often beat complex vector setups. I’ve seen the same in production: start with crisp, deterministic signals, then layer embeddings where they truly add value. This keeps systems debuggable and stable as you scale.

The interface choices matter just as much as the models. “Slack as the interface for human-AI collaboration” puts the agent where incidents already live, reducing friction and increasing adoption. Under the hood, they’ve been pragmatic with “PGVector and Postgres for retrieval experiments”, using “RAG (Retrieval-Augmented Generation)” and “Multi-agent orchestration” to chain context gathering, hypothesis formation, and action proposals. The north star is compelling: “AI as your company’s immune system”.

What impressed me operationally was the rigor around evaluation. Post-incident “time travel” evals let teams score AI accuracy after they know what really happened. That’s the standard we should all adopt: test the agent against reality, not just synthetic prompts, and feed those learnings back into prompts, tools, and guardrails.

Trust is the currency in incidents, so the product surface must reflect uncertainty with care. Building trust in AI isn’t just about precision—it’s about showing reasoning and uncertainty in ways humans understand. In other words, show the chain of thought as a structured artifact (signals considered, hypotheses rejected, evidence gathered), expose confidence bands, and always make it easy for humans to override or guide.

From a workflow standpoint, the investigation loop mirrors seasoned SRE practice: fast scoping, parallel checks and data sources, building hypotheses and refining findings, then proposing remediations paired with the context that justifies them. Human-agent collaboration here is not a handoff—it’s a tight copilot loop where the agent gathers, tests, and drafts, and the human confirms, prioritizes, and executes.

For platform and security leaders, this approach blends speed with safety. Clear permissions, auditable actions, blast-radius constraints, and CI/CD integration keep the AI inside defined guardrails while still delivering material acceleration. The payoff is higher deployment frequency without compromising reliability—because detection, triage, and rollback become faster and more repeatable.

My takeaway as a product leader: this is a blueprint for agentic AI in mission-critical workflows. Start in the tools users live in (Slack), nail retrieval with deterministic foundations, model the expert’s playbook (not just their summaries), and make evaluation a first-class part of the product. Do that well, and the AI goes from assistant to teammate—conservative when it should be, bold when the evidence supports it, and always legible to the humans in the loop.

The momentum around Incident.io’s AI SRE suggests where we’re headed next: deeper integrations, broader coverage across service catalogs, and richer automations that remain transparent and controllable. For teams investing in reliability, this is the moment to operationalize agentic AI—measured, auditable, and designed for trust—so you can move faster when it matters most.

Inspired by this post on Product Talk.

November 6, 2025
Urgent Alert: Spot Fraudulent Job Offers Impersonating Pendo—and Protect Your Career

In my role leading product management, I take brand trust and cybersecurity seriously—especially when it affects people’s livelihoods. Over the past few weeks, I’ve seen a troubling uptick in brand impersonation and social engineering targeting candidates. It’s a reminder that protecting our community isn’t just a technical problem; it’s a product management leadership and stakeholder management responsibility.

We want to warn you about recent instances of fraudulent job offers purporting to be from Pendo and/or its affiliate companies.

If you receive an unexpected outreach claiming to be from Pendo with a fast-track offer, requests for payment, or a push to move conversations to informal channels, treat it as a red flag. Scammers often spoof logos, clone profiles, and use vague role descriptions to create urgency. Their goal is to extract personal data, money, or access—classic social engineering tactics that undermine data governance and privacy-by-design principles.

Here’s how I advise candidates to protect themselves while keeping their job search momentum. Validate every opportunity through the company’s official careers page and confirm the recruiter’s identity through corporate channels. Check that email addresses and domains match publicly listed corporate information, and be wary of communication conducted exclusively through messaging apps. Never pay fees, buy equipment up front, or share sensitive data like Social Security numbers or banking information before a formal, verified offer is in place.

If something feels off, pause and verify. Contact the company via the channels listed on its website, ask for a video meeting with the recruiter using an official corporate account, and request written details on the role and interview process. If it’s fraudulent, report it to the company, the platform where the outreach occurred, and—when appropriate—local authorities. Acting quickly helps with threat detection and response and protects other candidates from harm.

From a product and security perspective, this is a cross-functional issue that benefits from AI risk management discipline. Strong signals include clear public guidance on recruiting practices, a dedicated reporting mailbox for suspected scams, and hardened email authentication (SPF, DKIM, DMARC). Pair these with privacy-by-design reviews for hiring workflows, recruiter verification checklists, and ongoing education for talent teams. These measures reduce attack surface while reinforcing brand integrity.

If you believe you’ve shared information with a fraudulent recruiter, take immediate steps: change any reused passwords, enable two-factor authentication, place fraud alerts or freezes with credit bureaus as appropriate, and monitor accounts for suspicious activity. Document all communications; they can help security teams and platforms act faster.

Recruitment fraud is emotionally taxing and can erode confidence in the process. Don’t let scammers slow your momentum. Stay vigilant, verify before you trust, and share this warning so others can avoid similar traps. If you’re ever unsure about a message that appears to come from Pendo, pause, validate through official channels, and prioritize your safety first.

Inspired by this post on Pendo – Best Practices.

October 25, 2025
Urgent Alert: Spot Fraudulent Job Offers Impersonating Pendo—and Protect Your Career

In my role leading product management, I take brand trust and cybersecurity seriously—especially when it affects people’s livelihoods. Over the past few weeks, I’ve seen a troubling uptick in brand impersonation and social engineering targeting candidates. It’s a reminder that protecting our community isn’t just a technical problem; it’s a product management leadership and stakeholder management responsibility.

We want to warn you about recent instances of fraudulent job offers purporting to be from Pendo and/or its affiliate companies.

If you receive an unexpected outreach claiming to be from Pendo with a fast-track offer, requests for payment, or a push to move conversations to informal channels, treat it as a red flag. Scammers often spoof logos, clone profiles, and use vague role descriptions to create urgency. Their goal is to extract personal data, money, or access—classic social engineering tactics that undermine data governance and privacy-by-design principles.

Here’s how I advise candidates to protect themselves while keeping their job search momentum. Validate every opportunity through the company’s official careers page and confirm the recruiter’s identity through corporate channels. Check that email addresses and domains match publicly listed corporate information, and be wary of communication conducted exclusively through messaging apps. Never pay fees, buy equipment up front, or share sensitive data like Social Security numbers or banking information before a formal, verified offer is in place.

If something feels off, pause and verify. Contact the company via the channels listed on its website, ask for a video meeting with the recruiter using an official corporate account, and request written details on the role and interview process. If it’s fraudulent, report it to the company, the platform where the outreach occurred, and—when appropriate—local authorities. Acting quickly helps with threat detection and response and protects other candidates from harm.

From a product and security perspective, this is a cross-functional issue that benefits from AI risk management discipline. Strong signals include clear public guidance on recruiting practices, a dedicated reporting mailbox for suspected scams, and hardened email authentication (SPF, DKIM, DMARC). Pair these with privacy-by-design reviews for hiring workflows, recruiter verification checklists, and ongoing education for talent teams. These measures reduce attack surface while reinforcing brand integrity.

If you believe you’ve shared information with a fraudulent recruiter, take immediate steps: change any reused passwords, enable two-factor authentication, place fraud alerts or freezes with credit bureaus as appropriate, and monitor accounts for suspicious activity. Document all communications; they can help security teams and platforms act faster.

Recruitment fraud is emotionally taxing and can erode confidence in the process. Don’t let scammers slow your momentum. Stay vigilant, verify before you trust, and share this warning so others can avoid similar traps. If you’re ever unsure about a message that appears to come from Pendo, pause, validate through official channels, and prioritize your safety first.

Inspired by this post on Pendo – Perspectives.

October 25, 2025
3 Powerful Ways AI Is Reshaping Cybersecurity—from Ruthless Attacks to Rapid Defense

Every week, I watch the cybersecurity landscape bend under the pressure of AI. The pace isn’t linear—it’s compounding. What worked for IT teams last quarter often needs a rethink today, and the difference between merely coping and truly competing lies in how quickly we adapt our strategy, tooling, and operating rhythms.

Learn the ways in which AI is transforming both cybersecurity offense and defense for IT teams.

From my vantage point leading product strategy, I see three shifts that matter most right now: AI is supercharging attackers, accelerating defenders, and reshaping governance. Together, they redefine how we prioritize investments, measure risk, and align product and security roadmaps.

First, AI has leveled up the offense. Large language models can industrialize social engineering—hyper-personalized spear-phishing at scale, deepfake voice notes that spoof executives, and highly convincing support chats that trick users into bypassing controls. Code-generation tools lower the barrier to crafting polymorphic malware and automating reconnaissance. The net effect is ruthless efficiency: more credible lures, faster campaigns, and broader reach with fewer human operators. I now assume adversaries have an AI co-pilot—and plan defenses accordingly.

Second, AI is accelerating the defense. Modern detection and response stacks are moving beyond rules to behavioral analytics—correlating identity signals, endpoint telemetry, and network events to spot subtle anomalies that signature-based tools miss. Copilot-style assistants are augmenting SecOps by summarizing incidents, explaining probable root cause, and proposing next steps. The aim isn’t blind automation; it’s decision acceleration—shrinking mean time to detect and respond while reducing analyst toil. On the build side, AI-assisted code scanning and dependency analysis help teams shift security left, catching vulnerabilities earlier and turning secure defaults into muscle memory.

Third, governance is being rewritten in real time. As AI models ingest sensitive data and generate code and content, data governance and privacy-by-design move from compliance checklists to active risk management. We’re formalizing AI risk management alongside traditional AppSec: model inventories, usage policies, red-teaming prompts, and guardrails against prompt injection and data leakage. Identity remains the control plane—zero trust principles, least privilege, and continuous verification become nonnegotiable. I’ve found that aligning security, product, and IT leadership on a single policy-as-code backbone prevents drift and keeps audits predictable.

Practically, I guide teams to start with a crown-jewel inventory: What data and systems would materially impact customers, revenue, or brand if compromised? Map data flows, instrument comprehensive telemetry, and prioritize detection coverage where it matters most. Choose AI to augment before you automate—prove the loop with humans in the middle, then graduate to higher autonomy levels with clear rollback paths and audit logs.

Culturally, this is a product problem as much as a security one. We bring empowered product teams and SecOps into the same room, set measurable objectives (signal-to-noise ratio, mean time to contain, escaped defect rate), and iterate with the same cadence we use for product features. When security outcomes are treated as customer outcomes, adoption soars and friction recedes.

The takeaway: AI has tilted the field, but not inevitably against defenders. With a clear AI strategy, disciplined data governance, and pragmatic automation, IT leaders can turn reactive security into a proactive advantage—meeting attackers’ speed with speed, and outlasting them with better judgment.

Inspired by this post on Pendo – Perspectives.

October 24, 2025