Introducing sensitive data redaction for Mastra observability. Automatically redact sensitive customer information from agent traces. Aug 10, 2026 With Mastra's new SensitiveDataFilter, you can automatically redact customer information from agent observability traces, or configure rules per-environment for application-specific fields. The SensitiveDataFilter is enabled by default and ships with 15 default value fields - including password, ssn, and auth. You can customize which fields to redact with the sensitiveFields array. Field matching normalizes case and separators, for example; api-key, api_key, and ApiKey would all match. You can also configure redaction styles, change the replacement token, and set different rules per-environment. E.g. partial for development, and full for production. Before the SensitiveDataFilter, keeping secrets and PII out of your agent traces meant writing a custom span processor to sanitize tool inputs. Now the SensitiveDataFilter is enabled by default, catching and redacting sensitive field names automatically. SensitiveDataFilter is a SpanOutputProcessor that recursively walks each span's attributes, metadata, input, output, and errorInfo - including nested objects, arrays, and JSON-encoded strings. To disable the functionality, set sensitiveDataFilter: false. Install @mastra/observability: Requires @mastra/[email protected] or later, added in PR #16234. A default Observability config automatically redacts the default values and replaces sensitive data with [REDACTED]. Additional configuration may be required to ensure all customer-specific sensitive data is redacted. Example output from default config: Define your own fields using the sensitiveFields array - this overrides the defaults, set the redactionStyle to full, and add a redactionToken. Use the configSelector to configure different rules per environment: NODE_ENV=development is the default, NODE_ENV=production selects production. Example output from extended config: Paul Scanlon Technical Product Marketing Manager Paul Scanlon sits between Developer Education and Product Marketing at Mastra. Previously, he was a Technical Product Marketing Manager at Neon and worked in Developer Relations at Gatsby, where he created educational content and developer experiences.

Announcing Trace Intelligence. Group traces into clusters. Jul 27, 2026 The hardest part of building an agent is ensuring it's accurate enough to ship into production. Teams can spend weeks or months reviewing user traces and turning them into agent fixes. That's why Mastra is excited to announce Trace Intelligence in beta today. Trace Intelligence is grouping traces into clusters so you can identify common goals, behaviors, sentiments, and outcomes across many runs. It's built into observability on the Mastra platform. While building its own agents, Trace Intelligence has helped Mastra prioritize fixes, select traces for evals, and verify that changes improve user experience. Trace Intelligence takes completed traces, extract a compact trace representation along with metadata, generates signals per trace including goal, sentiment, behavior, and outcome, embed each signal and cluster similar signals together. Mastra use UMAP for dimensionality reduction of signal embeddings and HDBSCAN for density-based clustering in the reduced space. Then, Mastra serve time-windowed views showing theme volume, trends, cross-signal flows, history, and representative traces. Trace intelligence is its second step towards agent learning. The full agent accuracy loop is something like: * review traces * create datasets * experiment with potential fixes; * ship fixes to prod Back in March, Mastra shipped Datasets and Experiments. Now, Trace Intelligence helps with the trace review and selection. After this, Mastra'll be working on automating the experiment flow by generating proposed fixes. Soon, you'll be able to automate the entire agent learning loop within Mastra.

Mastra npm attack: 141 packages backdoored via easy-day-js RAT. Fri Jun 19 Searching for Mastra npm hack, easy-day-js malware, or @mastra supply chain attack June 2026? On June 17, 2026, attackers republished 141 packages in the npm @mastra scope overnight - without touching Mastra's GitHub source. The payload rode in on a single swapped dependency: typosquatted easy-day-js instead of legitimate dayjs. Breaking - June 17, 2026: Security vendors including Socket, StepSecurity, and OX Security disclosed a coordinated npm supply-chain attack against Mastra - an open-source AI agent framework with millions of monthly downloads. BreachHistory indexes every compromised package version at pkg-npm-mastra-easy-day-js-202606. What happened. The attacker did not modify Mastra application source in Git. Instead they: * Published typosquatted easy-day-js - mirroring dayjs metadata (author, homepage, repo URL, version numbering) to pass casual review. * Shipped a clean bait version [email protected] on June 16, then weaponized 1.11.22 with a malicious postinstall hook (node setup.cjs). * Compromised dormant former contributor account ehindero and mass-republished 141 @mastra packages between roughly 01:12-02:39 UTC on June 17, each declaring "easy-day-js": "^1.11.21" so npm resolved the caret range to the malicious dropper. Account sergey2016 uploaded the malicious npm package; reporting ties both accounts to tutamail.com email substitution consistent with takeover. Legitimate prior @mastra releases carried GitHub OIDC provenance; compromised versions published from ehindero lacked SLSA attestations - a red flag teams can enforce in policy. Payload: two-stage RAT, not a simple stealer. Stage 1 is setup.cjs - roughly 4.5 KB of heavily obfuscated JavaScript run at install time. It disables TLS verification, beacons install paths, fetches stage 2 from 23.254.164.92:8000, spawns a detached background process pointed at C2 23.254.164.123:443, then deletes itself from disk. Stage 2 is a cross-platform Node.js remote access trojan (~41 KB) that: * Installs OS-level persistence (Windows Run key, macOS LaunchAgent, Linux systemd user unit) - surviving npm uninstall * Inventories 166 cryptocurrency wallet browser extensions and harvests browser history from Chrome, Brave, and Edge * Exfiltrates host, process, and environment reconnaissance - including high-value LLM API keys and cloud/CI credentials common in AI dev stacks * Polls for operator commands to download and execute arbitrary follow-on modules Socket flagged easy-day-js within six minutes of publication; StepSecurity demonstrated blocking the outbound C2 prevented stage-2 download entirely. There is no CVE - CVE scanners had no detection surface during active exploitation. Scale and who is at risk. OX Security cited ~8 million combined weekly downloads and ~29 million monthly across affected packages; @mastra/core alone exceeds 900,000 weekly installs. Anyone who ran npm install on a @mastra package during the June 17 exposure window - developer laptops, CI runners, cloud build agents - is in scope. Mastra targets AI agent workflows, so compromised hosts often hold OpenAI, Anthropic, and Google API keys alongside npm and GitHub tokens. Representative compromised versions. * @mastra/[email protected] (prior clean: 1.42.0) * @mastra/[email protected], @mastra/[email protected], @mastra/[email protected] * [email protected], [email protected] * Malicious dependency: [email protected] Immediate action checklist. * Audit dependency trees: npm ls easy-day-js across repos and CI images. * Pin or downgrade every @mastra package to the last provenance-verified release before June 17, 2026. * Treat affected hosts as compromised - do not assume uninstalling node_modules is sufficient. * Rotate secrets: LLM API keys, cloud credentials, npm tokens, GitHub PATs, SSH keys, and database URLs present on infected machines. * Hunt persistence: Windows HKCU\Run (NvmProtocal), macOS ~/Library/NodePackages/protocal.cjs, Linux ~/.config/systemd/nvmconf/. * Block egress to 23.254.164.92 and 23.254.164.123 at firewall/proxy. * Review CI logs for npm install steps between 01:00-03:00 UTC June 17, 2026. Why dependency-only attacks are hard to spot. This campaign highlights a structural gap: package tarballs looked like normal semver bumps from a known maintainer handle, and only one dependency field changed. Typosquats copied dayjs metadata so npm audit and visual lockfile review often showed nothing alarming. Install-time scripts execute before your application imports any @mastra code - so runtime SAST never runs. Teams should enforce provenance attestation requirements, block postinstall scripts in CI where feasible, and monitor registry publishes on scoped packages they depend on. Faq. Did Mastra confirm the incident? Third-party researchers and npm security vendors published detailed analyses June 17; check Mastra's official channels for vendor statements as they emerge. Is this related to Shai-Hulud or node-ipc? No - distinct campaign, distinct payload (easy-day-js typosquat), and distinct access vector (dormant @mastra maintainer token rather than atool or node-ipc maintainer abuse). Can I just delete easy-day-js from node_modules? Not safely. The RAT installs OS persistence outside node_modules; assume full host compromise until forensics clears the machine. Updated 2026-06-19.