Home
Mar 24, 2026
View All

LangChain's Agent Authorization Split and Notion's Japan/Korea Data Residency

The Short Version#

LangChain publishes the most practically useful agent architecture post of the week — a clean taxonomy of the two fundamentally different ways agents get authorized to act on user data — while Notion's data residency expansion to Japan and South Korea signals that enterprise AI compliance requirements are driving product roadmap in ways that weren't on most PMs' radar two years ago.

LangChain / LangSmith — Two Different Types of Agent Authorization#

Source: https://blog.langchain.com/two-different-types-of-agent-authorization/ Credibility: High (first-party LangChain blog post, published March 23, 2026 — from the team building production agent infrastructure)

What happened: LangChain published a post clarifying the two distinct authorization models in LangSmith Fleet: Assistants, which use the end user's own credentials when taking actions on their behalf, and Claws, which use a fixed set of credentials configured at deployment time. This distinction isn't just semantic — it has direct implications for security, auditability, user consent, and what failure modes look like when an agent acts incorrectly.

Key architectural patterns:

  • Assistants (user-credentialed): The agent acts with the permissions of the person who triggered it. If a user asks the agent to send a Slack message or update a CRM record, it does so using their Slack token or CRM login. Audit trails show the user's identity, not the agent's. Permissions are naturally scoped to what the user can already do.
  • Claws (service-credentialed): The agent uses a fixed service account or API key regardless of who invoked it. This is appropriate for background tasks (e.g., a nightly agent that processes a queue) but dangerous if misused — the agent can do anything the service account can do, regardless of who triggered it.
  • The post explicitly frames the choice as a trust and safety decision, not just a technical one: "which model you use determines who is responsible when something goes wrong"

Why it matters for PMs: This taxonomy cuts through a lot of vague "agents need permissions" hand-waving and gives you a concrete decision point for every agent workflow you're designing. The authorization model you choose determines your blast radius when an agent misbehaves, how you explain behavior to users ("the agent acted as you" vs. "the agent acted as a system"), and what your audit log looks like for compliance purposes. For PMs building at fintech companies or anywhere data sensitivity is high, the service-credentialed model (Claws) should require explicit justification — it's functionally a privileged process running on behalf of your entire system, not a specific user. The user-credentialed model (Assistants) is safer for user-facing workflows but requires careful handling of credential storage and refresh. Neither is always right. That's exactly why the framework is useful.

Critical questions:

  • How does LangSmith Fleet handle credential revocation for Assistants — if a user's token expires or they leave the organization, does the agent gracefully degrade or fail noisily?
  • The Claws model is safer for automation pipelines, but how does Fleet scope the blast radius of a misconfigured service credential? Is there role-based access control at the action level?
  • For enterprise customers with SOC 2 or HIPAA requirements, which authorization model produces the audit trail format that compliance teams actually need?
  • Does this architecture port cleanly to non-LangChain agent frameworks, or is it specific to Fleet's implementation?

Action you could take today: Pick one agent workflow your team is currently building or evaluating and explicitly answer: is this an Assistant (user-credentialed) or a Claws (service-credentialed) agent? If you don't have a clear answer, that's a product risk — schedule 30 minutes with your engineering lead to make the call explicit and document the rationale.

Notion — Data Residency Expansion to Japan and South Korea#

Source: https://www.notion.com/blog/notion-expands-data-residency-to-japan-south-korea Credibility: High (first-party Notion blog post, authored by Fuzzy Khosrowshahi, CTO of Notion — a CTO byline on a compliance post is a strong signal)

What happened: Notion announced that starting May 2026, Enterprise plan customers in Japan and South Korea will be able to keep their Notion data at rest in-region. This expands Notion's data residency options beyond the existing US and EU options. The announcement is authored by Notion's CTO, which signals this is a strategic priority for enterprise growth in Asia-Pacific, not a minor infrastructure update.

Key details:

  • Available starting May 2026 for Enterprise plan customers — not available on lower tiers
  • Covers Japan and South Korea specifically — both markets with strict data localization regulations (Japan's APPI, South Korea's PIPA)
  • "Data at rest in-region" — the specific framing matters: this covers stored data, not necessarily data in transit or processing
  • CTO-authored post suggests this required meaningful infrastructure investment, not a configuration toggle

Why it matters for PMs: Data residency requirements are increasingly a product feature, not just a legal checkbox — and this update is a clear signal that enterprise AI products are treating compliance infrastructure as a growth enabler. For PMs at B2B SaaS companies (or building enterprise tiers of consumer productivity tools), data residency is often the single blocker for closing deals with large customers in regulated markets. Japan and South Korea together represent a massive enterprise software market that Notion was effectively locked out of for large, compliance-sensitive deployments. The Enterprise-only positioning is also a deliberate product decision — data residency is being used as a tier differentiator, not a universal entitlement. That's worth noting if you're thinking about how to structure your own compliance features across pricing tiers. And the Custom Agents launch from March 20 combined with this expansion tells a coherent story: Notion is building enterprise-grade infrastructure (agents + compliance + security) to move upmarket.

Critical questions:

  • Does "data at rest" residency cover all Notion data, or are there carve-outs for AI features that process data through non-regional endpoints?
  • How does data residency interact with Custom Agents — if an agent calls an external API or LLM, does that data leave the region, and how is that disclosed to customers?
  • What's the roadmap for additional APAC markets (Australia, Singapore, India)? Stopping at Japan and South Korea suggests either infrastructure cost constraints or demand prioritization — which one?
  • Is the May 2026 date firm? Enterprise deals are often gated on compliance features, and a slip would have revenue implications.

Action you could take today: If your product has any enterprise prospects in Japan or South Korea (or plans to), check whether data residency is currently on their evaluation criteria. If yes, you now have a Notion announcement to reference as market precedent when building the case for your own roadmap investment.

GitHub — AI-Powered Application Security Coverage Expansion#

Source: https://github.blog/security/application-security/github-expands-application-security-coverage-with-ai-powered-detections/ Credibility: High (first-party GitHub blog post, published March 23, 2026)

What happened: GitHub expanded its application security coverage by adding AI-powered detection capabilities. Based on the title and GitHub's existing security product (Advanced Security / Code Scanning), this extends the set of vulnerabilities and security patterns that GitHub's scanning can identify, using AI to catch issues that rule-based static analysis would miss. This builds on GitHub's existing Copilot Autofix product, which already uses AI to suggest fixes for identified vulnerabilities.

Key context:

  • GitHub Advanced Security already includes Code Scanning (static analysis), Secret Scanning, and Dependency Review
  • AI-powered detections likely extend Code Scanning's coverage to semantic and contextual vulnerabilities — the kinds that require understanding intent, not just pattern matching
  • Autofix, which was launched in 2024, already uses AI to suggest one-click fixes for flagged issues; expanded detection coverage means more entry points for that workflow
  • This ships as part of GitHub's broader security posture push ahead of RSAC 2026 (April), where Microsoft also signaled enterprise agent security as a conference theme

Why it matters for PMs: Security features are increasingly a product differentiator at the platform level, not just an enterprise checkbox. For PMs building developer tools or any platform where code gets written and deployed, the pattern here is worth studying: GitHub is using AI to expand the coverage of an existing rule-based system, not to replace it. That's a meaningful product architecture choice — hybrid rule-based + AI detection is more defensible than pure AI (false positive rate is lower, auditability is higher) and more capable than pure rules (catches novel patterns). If your product has any rule-based classification, moderation, or detection system, this is the pattern to model: AI as coverage expander, rules as ground truth, with human review at the edges. Also relevant: GitHub is shipping this the same week they posted about Squad (multi-agent coordination) — together, they suggest GitHub is building a security-by-default posture into the agentic development workflow, not treating security as a separate layer.

Critical questions:

  • What's the false positive rate for AI-powered detections versus rule-based ones? If AI-powered findings generate more noise, developer trust in the scanning system degrades.
  • Is this available across all GitHub plans or only Advanced Security (enterprise-gated)? That determines actual developer reach.
  • How does expanded security coverage interact with Copilot's code suggestions — does Copilot learn from flagged patterns to avoid suggesting vulnerable code?
  • What categories of vulnerabilities are newly covered? Without specifics, "expanded coverage" is hard to evaluate against alternative tools like Snyk or Semgrep.

Action you could take today: If your team uses GitHub Advanced Security, check the Code Scanning alert feed this week for any new alert categories that weren't appearing before. If AI-powered detections are active, you'll see new finding types — evaluate one of them against your current engineering triage process to determine whether the signal-to-noise ratio justifies the expanded coverage.

Quick Hits#

  • OpenAI launches Sora 2 and the Sora app with explicit safety-by-design framing, including new safety features and controls for video generation (March 23, 2026): https://openai.com/index/creating-with-sora-safely

  • Stripe published research testing Adaptive Pricing across 1.5M checkout sessions, demonstrating rigorous methodology for measuring friction-reduction impact on conversion and AOV — directly relevant for fintech PMs thinking about dynamic pricing patterns (March 19, 2026): https://stripe.com/blog/product

  • Cursor launches Composer 2 with per-token pricing for frontier models, representing a significant product architecture shift toward consumption-based pricing for AI coding tools (March 19, 2026): https://cursor.com/changelog/composer-2

  • Sam Altman steps down from Helion Energy's board as OpenAI and Helion explore working together "at significant scale." Altman retains a financial interest and will recuse himself from deal negotiations — a corporate governance move with OpenAI's energy strategy implications (March 23, 2026): https://x.com/sama

  • Aravind Srinivas appeared on Stanford GSB's "View From The Top" podcast discussing Perplexity's business model and acknowledged on X that Google is meaningfully stronger than Perplexity at mobile navigation-based searches — a rare public concession of a specific capability gap (March 20, 2026): https://www.gsb.stanford.edu/insights/perplexitys-aravind-srinivas-infinite-value-knowledge

The Thread#

Compliance infrastructure is becoming a product feature, not a cost center. Notion's data residency expansion (Japan, South Korea), GitHub's AI-powered security coverage, and LangChain's explicit agent authorization taxonomy all point to the same shift: the enterprise adoption blockers for AI products are now governance and compliance, not capability. A year ago, the question was "can the AI do the thing?" Now the question is "who is responsible when it does the thing incorrectly, and can we prove it to an auditor?" The teams building toward that second question — with clear auth models, regional data controls, and AI-assisted security coverage — are the ones that will close enterprise deals in 2026.

Sit With This#

LangChain's post draws a sharp line between two agent authorization models: one where the agent acts as the user (scoped to their permissions, attributable to their identity), and one where the agent acts as a service account (unbounded by any specific user, potentially acting on behalf of the entire system).

For your agent product or feature: Which model are you using — and did you choose it deliberately, or did it just emerge from how you set up credentials? If a user asks "who authorized that action," can you give them a clear answer? If you can't, you have the Claws model whether you intended it or not.

Sit With This is a daily reflection prompt. Take 5 minutes. One concrete answer beats three abstract ones.