Cloudflare introduced Temporary Cloudflare Accounts for AI agents, allowing them to deploy Workers without human-driven signup or authentication. With `wrangler deploy --temporary`, an agent receives a temporary account, API token, and deployment URL, then has 60 minutes to claim the account. If unclaimed, the account and its resources are automatically deleted.
## Why Frictionless Deployment Matters
- Background agents often operate without a human available to complete OAuth, copy tokens, or approve MFA.
- Temporary deployments support the agent’s rapid write → deploy → verify iteration cycle.
- Throwaway environments let agents test code cheaply and independently.
- Agent platforms increasingly need deployment workflows that work without requiring users to create accounts on unfamiliar services.
## How Temporary Accounts Work
- The feature is integrated into Wrangler, Cloudflare’s CLI for creating, configuring, and deploying projects.
- When an unauthenticated deployment encounters the normal signup barrier, Wrangler informs the agent about the `--temporary` option.
- Running `wrangler deploy --temporary` provisions:
- A temporary Cloudflare account
- An API token for Wrangler
- A claim URL that can be returned to the user
- The temporary account can be reused for multiple deployments during the 60-minute window.
## Agent Deployment and Iteration
- An agent can create a TypeScript “Hello World” Worker, deploy it, and use the returned preview URL to verify the result.
- It can then modify the source and redeploy without repeating account setup.
- Agents can use this loop to test and refine applications autonomously.
## Claiming or Expiring the Account
- Users can open the claim link, sign up for or sign in to Cloudflare, and permanently take ownership of the temporary account.
- Claiming includes associated Workers, databases, and other bindings.
- Unclaimed accounts are automatically deleted after 60 minutes.
## Broader Agent Provisioning Efforts
- Cloudflare is also working with Stripe on protocols for agents to create accounts, start subscriptions, register domains, and obtain deployment credentials without manual token or payment entry.
- Its collaboration with WorkOS on `auth.md` aims to support agent-driven account creation through established OAuth standards.
- Temporary accounts are positioned as one step toward making Cloudflare and other services easier for AI agents to use.
Developers should update Wrangler and try `wrangler deploy --temporary` for autonomous, short-lived deployments, while consulting Cloudflare’s documentation for current limitations.
Technical Writing at Toss has evolved from producing documents to designing organizational knowledge systems. The core argument is that code captures outcomes but not the context, decisions, and history behind them—information that both employees and AI need. Toss’s Technical Writing Chapter therefore aims to make knowledge discoverable, structured, and increasingly self-sustaining, with the long-term goal of making the chapter unnecessary.
### Why Code Alone Is Not a Sufficient Source of Truth
- Code records what a system does, but rarely explains:
- Why it was designed that way
- Which alternatives were considered
- What organizational history shaped the decision
- Employees often reconstruct context from colleagues’ memories or years-old messenger threads.
- AI faces the same problem: it understands general knowledge but lacks an organization’s internal context.
- A true Single Source of Truth requires both the code and the surrounding knowledge that explains it.
### From Writing Documents to Bringing Knowledge to People
- Early work focused on creating onboarding documentation for the frontend chapter.
- The team recognized that well-written documents are ineffective if people do not actively read or find them.
- Toss created “Parkssi,” a chatbot integrated into messaging tools and IDEs:
- Users ask questions conversationally.
- Answers are based on existing documents.
- Sources are provided for verification.
- Instead of requiring employees to search for documents, the knowledge reaches them where they work.
- Teams that previously ignored documentation began requesting similar systems to reduce repetitive questions and capture implicit knowledge.
### From Documents to Knowledge Systems
- A knowledge system collects scattered information from code, conversations, deployments, and other sources.
- It structures that information so both humans and AI can understand and use it through questions and automation.
- Properly designed systems:
- Increase productivity across the organization
- Reduce communication costs as the company grows
- Help employees adapt quickly and consistently
- Toss defines knowledge as verified information that helps people understand situations, make better decisions, and act within a specific context.
### The Four Responsibilities of Toss’s Technical Writing Chapter
- **Build products:** The chapter develops and operates “Todok,” an internal knowledge-management platform.
- **Lead organizational documentation:** TWs work directly with teams to collect and organize knowledge according to each group’s needs.
- **Automate Technical Writing:** AI workflows and automation help employees create and review documentation with consistent quality.
- **Shape documentation culture:** The chapter runs company-wide sessions, documentation guilds, and knowledge committees focused on making knowledge easier for AI and people to use.
### A Broader Definition of the Technical Writer
- Although the job title remains “Technical Writer,” the role now resembles a knowledge-infrastructure designer.
- The role expanded by following organizational problems rather than staying within a fixed professional boundary.
- The chapter’s ultimate goal is for teams to create and manage knowledge independently, eliminating the need for a dedicated TW chapter.
- The series will explore Toss’s knowledge product, failed documentation approaches, automation of TW work, and the path toward self-sufficient organizations.
Technical writers can create greater value by designing systems that make knowledge continuously available—not merely by writing more documents. As AI reshapes every profession, expanding a role around the problems it must solve is presented as an opportunity for any discipline.
Toss Securities operates Spark Connect as a production service on Kubernetes so analysts and engineers can use Spark without complex setup. Spark Connect replaces per-application Drivers with long-running servers, making clients lighter and sessions faster, but it also introduces shared-failure and resource-contention problems. The post argues that production reliability requires both reducing server-wide failure triggers and distributing sessions across multiple replicas.
## How Classic Spark Works
- Spark consists of:
- A **Driver**, which plans jobs, schedules tasks, and collects results.
- **Executors**, which perform the distributed computations.
- In Classic Spark:
- **Client mode** runs the Driver inside the client process.
- **Cluster mode** launches the Driver in the cluster for each submitted application.
- Both modes assume that one application has one Driver and one workload.
- Clients also need Spark libraries, JVM support, and configuration.
## What Spark Connect Changes
- Spark Connect turns the Driver into a pre-started, long-running server.
- Clients send unresolved logical plans encoded with Protocol Buffers over gRPC.
- The server handles analysis, optimization, scheduling, and execution.
- Results are streamed back using Arrow.
- This resembles a database accessed through JDBC.
### Benefits
- **Thin clients:** Clients do not need the full Spark runtime or JVM.
- **Language and platform independence:** Notebooks, BI tools, SQL clients, and different programming languages can use the same server.
- **Fast session creation:** Sessions connect to an already-running server.
- **Better client-failure tolerance:** A disconnected notebook does not necessarily terminate server-side work.
## Problems Created by Shared Long-Running Servers
Spark’s internal design often assumes “one application equals one workload.” Sharing one application across many users breaks that assumption.
### A Shared Driver Becomes a Single Point of Failure
- Multiple sessions share one `SparkContext` and Driver JVM.
- A Driver failure terminates all sessions, jobs, and caches attached to it.
- Spark’s global `spark.executor.maxNumFailures` counter can shut down the entire application after enough executor failures.
- Because all sessions contribute to the same counter, one user’s unstable or memory-intensive query can terminate unrelated users’ workloads.
- The counter is global, persists over time, and is separate from per-query task-level fault tolerance such as `spark.task.maxFailures`.
### Resource Contention and Scheduling Limits
- `newSession()` isolates SQL state and namespaces, but not CPU, memory, or executors.
- Heavy workloads can occupy all task slots and delay smaller queries.
- FIFO scheduling favors earlier jobs, and Spark does not preempt tasks already using slots.
- Fair Scheduler pools can influence task-slot ordering, but cannot provide true CPU or memory isolation.
- Spark Connect does not automatically propagate `spark.scheduler.pool` to the server-side execution thread, causing queries to fall into the default pool unless the server explicitly assigns pools.
- Actual resource isolation must therefore be implemented outside Spark’s task scheduler.
### Fixed Server Capacity
- A server’s image, Driver and Executor resources, and Spark configuration are fixed when it starts.
- Dynamic Resource Allocation can adjust executor counts, but cannot change the server’s basic specification.
- Flexible scaling and team-level isolation require creating or replacing servers, which is addressed in a later part of the series.
## Reducing Server-Wide Failures
Before adding replicas, Toss Securities reduces the chance that one bad query can kill the shared server.
- Set `spark.executor.maxNumFailures` effectively high enough to disable the global shutdown mechanism.
- Use `spark.executor.failuresValidityInterval` to periodically clear accumulated failure records.
- Rely on query-scoped controls:
- `spark.task.maxFailures` stops tasks that repeatedly fail due to OOMs or exceptions.
- `spark.stage.maxConsecutiveAttempts` stops jobs whose stages repeatedly fail, such as from shuffle-fetch errors.
- These limits must be tuned carefully: overly aggressive values can cause healthy queries to fail during temporary infrastructure problems.
- With this approach, executor failures terminate the problematic query rather than the entire Spark Connect server.
## Protecting Driver Memory from Large Results
- Spark Connect streams query results through the Driver, so a large `collect()` can threaten Driver memory.
- `spark.driver.maxResultSize` aborts an action when accumulated task results exceed the configured limit.
- The limit is checked before large executor-side results are fetched into Driver memory.
- The default 1 GB value assumes a single workload; in a multi-session server, it should be reduced or tuned based on the number of concurrent queries.
## Replicating Spark Connect Servers
- Configuration alone cannot prevent Driver OOMs, node failures, or other catastrophic events.
- The stronger isolation boundary is a separate SparkContext.
- Multiple identical Spark Connect replicas are deployed:
- Each replica has its own Driver, SparkContext, and Executors.
- A failure affects only the sessions assigned to that replica.
- Other replicas can continue accepting sessions.
- Replica-based deployment reduces the blast radius from the entire Spark Connect service to an individual server instance.
## Practical Recommendation
For a multi-user Spark Connect service, disable global executor-failure shutdown, enforce query-level failure limits, protect Driver memory with `spark.driver.maxResultSize`, and use multiple replicas to contain unavoidable Driver or node failures. Scheduler pools can improve ordering, but they should not be treated as true resource isolation.
Technical Writers (TWs) can contribute far beyond writing documentation: they can lead product teams and build systems that turn knowledge into an organizational asset. Toss’s Knowledge System Team created “todoc,” an internal platform that makes documentation easier to write, centralizes scattered knowledge, and enables AI access. Its broader goal is to make documentation emerge naturally from daily work and remain accurate without constant manual maintenance.
## TWs as Product Owners and Makers
- The author leads a product team of developers, designers, and TWs.
- Their responsibilities include:
- Setting product direction, roadmap, and priorities
- Interviewing users and bringing insights to the team
- Planning features
- Building features directly with AI tools
- TW expertise is especially valuable because TWs have deeply considered:
- Why documents are difficult to read
- What makes documentation effective
- How information should be structured for AI consumption
## Why Toss Built Todoc
Todoc was launched to address weaknesses in Toss’s existing documentation environment.
- Static-site-generated documentation required users to:
- Clone a repository
- Write Markdown
- Submit pull requests
- Wait for review
- This workflow was familiar to developers but created major barriers for designers, PMs, and other non-developers.
- Existing documentation tools accumulated outdated policies, unfinished notes, and unexplained content, creating “documentation debt.”
- Knowledge was fragmented across:
- Static sites
- Documentation tools
- Code
- Collaboration messengers
- Individual employees’ knowledge
After its beta launch, Todoc grew to more than 500 documents and 40,000 valid pages, with over 1,000 monthly users.
## Todoc’s Four Core Values
### Easy Documentation for Everyone
- Anyone can create or edit documents immediately.
- Content can be connected from GitHub, documentation tools, internal messengers, and other sources.
- The platform removes the technical and procedural barriers to documentation.
### AI-Ready Knowledge
- Well-organized documentation can be used by team bots and other AI tools.
- Todoc supports API, CLI, and MCP access.
- Teams use it for request bots, product specifications, and other workflows.
### A Single Source of Truth
- Todoc consolidates scattered sources into complete, centralized documents.
- Users can determine which information is current without searching across multiple systems.
- The platform serves as the organization’s SSoT (Single Source of Truth).
### Scalable Infrastructure
- Teams no longer need to select, build, or maintain their own documentation infrastructure.
- Each team can have its own space on a shared platform.
- The model is being expanded to Toss affiliates.
## Automating Documentation Quality and Maintenance
Lowering the barrier to writing creates a new challenge: maintaining quality.
- TW judgment is being converted into:
- AI proofreading
- Automated document reviews
- Bots that generate initial drafts
- Todoc is also designed to create documentation automatically from:
- Decisions and discussions in internal messengers
- Code changes
- Ongoing project conversations
- The system aims to update documents without relying on someone remembering to maintain them.
- It evaluates whether knowledge is still valid by checking:
- Whether policies match implemented code
- Whether information is actively used
- How recently it was updated
## The Evolution of TW Expertise
The role is shifting from writing excellent documents manually to designing systems that consistently produce and maintain excellent documentation.
- Experience understanding why documents are hard to read becomes standards for human- and AI-readable content.
- Judgments about what makes a good document become criteria for AI review and automated editing.
- Expertise in identifying outdated information becomes a system for validating knowledge.
- TWs increasingly focus on:
- Creating places where knowledge can gather
- Defining quality standards
- Encoding human judgment into systems
- Generating documentation through normal work
- Keeping knowledge continuously updated
The practical vision is an organization where outdated documents trigger their own notifications, project work leaves behind organized records, and recurring explanations are preserved for future employees. Toss’s Technical Writing Chapter is therefore working to systematize TW expertise and establish documentation governance so teams can document effectively without constant manual intervention.
Toss Design Chapter’s AI Contest invited designers to build anything with AI, resulting in 122 projects over one month. The examples show that designers primarily used AI to improve existing work—making it faster, more persuasive, and higher quality—rather than creating entirely new kinds of work. The article recommends starting with a frustrating, repetitive task or a frequently repeated communication problem.
## Automating Repetitive Work
- A color-extraction tool automatically identifies and adjusts colors from images for use in UI.
- Color extraction had been an unresolved challenge at Toss because results varied widely by image.
- Designers used AI to draft the logic, test it against many sample images, and rapidly refine it.
- The resulting system is now used for product-card colors in Toss Shopping.
## Reducing Collaboration Costs with a Personal Bot
- A Slack bot was trained on a designer’s knowledge, past discussions, and reference materials.
- It creates draft answers to the many design and requirements questions the designer receives each day.
- Team members can send the draft as-is or revise it before responding.
- The bot learns from those revisions, improving its answers to similar questions over time.
- The designer described the result as feeling like becoming “1.5 people,” and other Toss designers began creating their own bots.
## Persuading Through Interactive Prototypes
- A designer built a functioning prototype of a stock-trading desktop interface instead of presenting only static screens.
- Users could drag panels, rearrange them, and resize windows, with the interface responding accordingly.
- Showing the intended interactions directly reduced the risk that design ideas would be misunderstood during development.
- The working prototype helped align designers and developers and persuade the product owner.
## Pushing Quality Within Tight Deadlines
- AI-generated motion graphics were created for the key visual of Toss Bank’s recruitment website.
- Each job category needed its own animation despite a very short schedule.
- The designer created the foundational images manually and repeatedly refined Kling prompts to achieve the desired results.
- Human-designed starting and ending frames combined with AI-generated motion allowed all category animations to be completed in a single day.
## Four Ways to Start Using AI
- **Efficiency:** Hand off one especially annoying repetitive task to AI.
- **Replication:** Build a bot to answer questions you repeatedly handle yourself.
- **Persuasion:** Turn designs that require verbal explanation into working prototypes.
- **Quality:** Use AI to reach a higher level of polish within a limited timeframe.
The practical recommendation is to begin with an existing task rather than searching for an entirely new AI application. Choose one area where AI can save time, communicate intent more clearly, or help raise the final quality.
Amazon EC2 G7 instances are now generally available with NVIDIA RTX PRO 4500 Blackwell Server Edition GPUs and custom sixth-generation Intel Xeon processors. Compared with G6 instances, they provide up to 4.6× higher AI inference performance and 2.1× better graphics performance. AWS positions them for AI inference, rendering, video, virtual desktops, spatial computing, and GPU-accelerated analytics.
## GPU and Performance Improvements
- Each GPU provides 32 GB of memory, with up to 256 GB across eight GPUs.
- GPU memory capacity is 1.33× higher and bandwidth is 2.45× higher than G6.
- GPUs include fifth-generation Tensor Cores and fourth-generation RT Cores.
- G7 instances accelerate analytics workloads running on Amazon EMR with Amazon EKS.
## Networking and Storage
- Up to 700 Gbps of EFA-enabled networking—seven times the G6 throughput.
- Up to 7.6 TB of local NVMe SSD storage keeps large models and datasets close to the GPUs.
- Support for NVIDIA GPUDirect P2P and GPUDirect RDMA with EFA enables low-latency GPU communication across GPUs, nodes, and FSx for Lustre.
## Video Processing
- Ninth-generation NVENC and sixth-generation NVDEC engines support 4:2:2 encoding and decoding.
- They deliver up to 1.5× more concurrent video streams than G6 instances.
## Instance Configurations
- Seven instance sizes are available.
- Configurations offer up to:
- 8 NVIDIA RTX PRO 4500 GPUs
- 192 vCPUs
- 768 GiB of system memory
- 700 Gbps network bandwidth
- 7.6 TB local NVMe storage
- Detailed instance specifications were listed as “coming soon” in the announcement.
## Software and Availability
- AWS provides Deep Learning AMIs and NVIDIA Workstation AMIs with preinstalled drivers.
- Amazon EKS users should build AMIs with NVIDIA driver version R595.
- Supported operating systems include Amazon Linux, Ubuntu, RHEL, and Windows Server.
- NVIDIA integration supports DirectX, Vulkan, and OpenGL.
- G7 instances are initially available in US East (Ohio) and US West (Oregon).
- Purchasing options include On-Demand, Savings Plans, Spot Instances, and Dedicated Instances for selected sizes.
G7 instances are a strong option for GPU-intensive workloads requiring higher inference, graphics, networking, and video performance. Organizations can launch them through the EC2 console and evaluate pricing across the available purchasing models.
Amazon ECS now supports 20-second high-resolution metrics for faster service auto scaling. AWS reports that scale-out triggers improved from 363 to 86 seconds, while total scaling and task provisioning dropped from 386 to 109 seconds. The update helps applications handle traffic spikes more reliably, reduce excess baseline capacity, and achieve aggressive scaling with simpler target-tracking policies.
## Faster Scaling with High-Resolution Metrics
- ECS service auto scaling can use predictive, scheduled, or reactive target-tracking policies.
- New 20-second metrics allow ECS to detect workload changes faster than standard 60-second metrics.
- AWS benchmarking showed:
- 76% faster scale-out triggering, or 4.2× improvement.
- 72% faster total scaling and task provisioning, or 3.5× improvement.
- Faster scaling can reduce latency and failures during sudden demand increases.
## Lower Costs and Simpler Configuration
- Applications may reduce baseline task counts because capacity can be added quickly during spikes.
- This can lower compute costs without sacrificing availability.
- High-resolution target tracking can provide aggressive scaling behavior that previously required custom step-scaling policies.
## Configuration and Supported Metrics
- Enable high-resolution metrics for the ECS service, then configure a target-tracking scaling policy.
- New options include:
- `ECSServiceAverageCPUUtilizationHighResolution`
- `ECSServiceAverageMemoryUtilizationHighResolution`
- The feature works with AWS Fargate, ECS Managed Instances, and Amazon EC2.
- It can be configured through the ECS console, AWS SDKs, AWS CLI, Application Auto Scaling, or CloudFormation.
- Existing services must first enable high-resolution metrics and complete deployment before their scaling policy can be updated.
## Cost and Availability
- The ECS feature itself has no additional charge.
- High-resolution CloudWatch metrics incur additional CloudWatch costs, unlike standard 60-second metrics.
- The capability is available now.
For workloads with unpredictable or rapid traffic changes, enabling high-resolution metrics with target tracking can improve responsiveness while reducing the need for overprovisioned ECS tasks.
A scalable AI vulnerability program should be built around a model-agnostic harness rather than a single model, prompt, or agent session. The harness must preserve state, support resumable investigations, cross-check findings with different models, and trace issues across repositories. The authors recommend starting small with database-backed Recon, Hunt, and Validate stages, expanding only when operational bottlenecks justify it.
## Why a Harness Is Needed
- Generic coding agents are poorly suited to large-scale security analysis because they:
- Hold only one hypothesis at a time.
- Exhaust their context windows while exploring real repositories.
- Lose important information during context compaction.
- Subagents help, but they do not provide the persistence, deduplication, resumability, and cross-run coordination required for security investigations.
- The system should treat models as interchangeable components:
- One model can discover vulnerabilities.
- Another can independently validate them.
- Different models expose different classes of bugs and reduce shared blind spots.
- The harness, rather than any particular frontier model, is intended to be the durable investment.
## The Original Security-Audit Skill
The authors began with an approximately 450-line skill designed to audit one repository in a single session. Its seven-phase workflow included:
- Three parallel reconnaissance agents producing `architecture.md`.
- Hunter agents attacking the code by vulnerability class.
- Adversarial validators attempting to disprove findings.
- A human-readable vulnerability report for surviving findings.
- A schema-checked `findings.json` file.
- Mechanical validation of referenced functions and line numbers.
- A fresh agent independently re-verifying every finding before submission to an ingest API.
This skill became the blueprint for the later pipeline:
- Recon agents became the Recon stage.
- Attack-class hunters became Hunt.
- Adversarial reviewers became Validate.
- Reports became structured findings.
- Independent re-verification remained a separate validation step.
## Limitations of Single-Session Audits
A single run found only about half of the bugs discovered across multiple runs, and it tended to find simpler vulnerabilities rather than subtle ones. Repeating the skill many times and manually diffing results quickly became impractical.
The authors identified three major bottlenecks:
- **Context exhaustion:** Long sessions cause the model to forget previously investigated bugs. The solution is to externalize state and use the model as a stateless computation engine.
- **Poor persistence:** Crashes, rate limits, and connection failures can erase hours of progress if work is not stored incrementally.
- **Lack of cross-repository reasoning:** Auditing one repository in isolation misses vulnerabilities at the interfaces between applications and shared components.
## Recommended Minimal Architecture
The authors advise building only the infrastructure needed to address current problems:
- Store Recon, Hunt, and Validate stages in a database.
- Use a separate validator that cannot submit its own findings, reducing confirmation bias.
- Defer cross-repository tracing until multiple important repositories need to be analyzed together.
- Defer a dedicated deduplication agent until the system produces too much duplicate or low-quality output.
- Begin with a well-tuned development skill, then add pipeline stages only when a specific limitation is slowing the work.
## Enterprise-Scale Direction
A mature vulnerability harness should continuously scan a fleet of repositories, trace dependencies across them, and reduce thousands of raw candidates to a smaller queue of verified, actionable fixes. Frequent model interchange and independent validation are central to maintaining coverage as models change or become unavailable.
The practical recommendation is to invest first in durable orchestration and state management, not allegiance to a particular model. A simple, resumable Recon–Hunt–Validate pipeline is the appropriate starting point, with cross-repository analysis and advanced deduplication added only as scale demands.
Project Galileo, launched by Cloudflare 12 years ago, provides free cybersecurity services to more than 3,400 civil society websites across 120 countries. Its anniversary report shows that journalists, human rights groups, and nonprofits face more frequent and intense attacks than other Internet users, especially during politically sensitive work. Cloudflare is responding with expanded research, case studies, partnerships, and a call for accessible security protections.
## Project Galileo’s Mission and Reach
- The program protects journalists, human rights defenders, and nonprofit organizations from being forced offline.
- It now supports more than 3,400 websites in 120 countries.
- Cloudflare’s global network spans more than 335 cities in 125 countries, with over 20% of the web behind its infrastructure.
## Cyberattacks Targeting Civil Society
Cloudflare’s first comprehensive annual report compares threats against civil society with attacks against Internet users more broadly.
- DDoS attacks were the most common threat, often lasting for days or weeks.
- Civil society organizations faced website vulnerability exploitation attempts at more than seven times the rate of other Cloudflare customers.
- Media organizations were especially affected.
- Journalists working in exile received nearly four times more malicious traffic than journalism organizations overall.
- Almost 10% of emails processed for civil society organizations contained potential phishing material.
- Attacks often coincided with investigative reporting, public advocacy, or other critical organizational activities.
Cloudflare calls for affordable cybersecurity, greater transparency around cyberattacks and Internet shutdowns, and default integration of AI-aware and post-quantum protections. The company plans to publish the report annually to track changing threat patterns.
## Case Studies of Project Galileo Participants
Sixteen case studies illustrate the varied security needs of participating organizations, including:
- Digital rights groups such as SHARE Foundation.
- Investigative and independent media organizations, including OCCRP, elTOQUE, and China Digital Times.
- Organizations documenting conflict and human rights abuses, such as Ukraine War Archive.
- Research and public-interest institutions including Our World in Data and the Bulletin of Atomic Scientists.
- Environmental, legal, scientific, and humanitarian groups such as Sea Shepherd Brazil, Activist Rights, and the Royal Meteorological Society.
## Expanding the Partner Network
Project Galileo depends on 59 civil society partners that review and approve applications.
- Partners contribute local expertise and help identify organizations that need protection.
- Previous collaborations produced initiatives such as email security with Protect.ngo and Internet measurement work through UNICEF’s Giga project.
- Cloudflare has focused on expanding access beyond North America and Europe through regional events and partnerships.
- Recent Asia-Pacific partners include EngageMedia and the OpenCulture Foundation.
- The anniversary announcement introduces three additional partners serving journalists, including the International Center for Journalists and Media Cluster Norway.
Project Galileo’s next phase combines threat intelligence, direct protection, regional partnerships, and specialized services for journalism organizations. Its broader recommendation is that reliable cybersecurity should be treated as essential infrastructure for civil society and public discourse.
Link’s survey and transaction data show rapidly growing consumer engagement with AI. Among 250 million Link customers, spending on AI products—especially AI app-building platforms—has surged, with top spenders nearly doubling their monthly AI spending in one quarter. Stripe argues this growth points toward a need for payment infrastructure that allows AI agents to transact on users’ behalf.
### Growing Spending on AI Products
- A survey of 394 Link customers found:
- 80% had used a chat-based AI agent in the previous month.
- 50% used AI for shopping research at least monthly.
- The top 10% of AI spenders increased monthly spending from:
- $183 in December 2025
- $359 in March 2026
- This cohort previously took 22 months to grow from $84 to $183, but doubled that amount in only three months.
- Median spending also rose, from $60 to $72 per month.
### Strong Demand for AI App Builders
- Spending growth was even greater for platforms such as Replit, Lovable, and Bolt.
- The highest-spending Link customers now spend five times more each month on AI app-building platforms than they did in January 2025.
- This suggests users are investing not only in AI tools, but also in platforms that let them create software with AI.
### Payments for AI Agents
- As AI agents become more capable and common, they will need to purchase goods and services from businesses and potentially from one another.
- Stripe’s Link wallet for agents is designed to support this activity by:
- Letting users authorize agent payments.
- Providing configurable spending controls.
- Giving agents purchasing access across Stripe sellers.
- Providing businesses with verified transactions without requiring custom integrations.
Stripe’s data indicates that AI adoption is translating into substantial spending, particularly on AI development platforms. Businesses preparing for agent-driven commerce may benefit from supporting secure, user-authorized agent payments.
GitLab 19.1 expands the AI Catalog from a manually triggered tool into a governed automation platform. New event-driven Duo Flow triggers, configuration validation, agent restrictions, and model allowlists help enterprises run AI workflows continuously while maintaining security and operational control. The release is designed to make agentic automation safer and more reliable at production scale.
## Event-Driven Duo Flow Automation
- Four new triggers let flows respond automatically to GitLab events:
- Merge request code conflicts
- Draft merge requests becoming ready for review
- Merge request approvals
- New work item creation
- These triggers enable automated conflict summaries, compliance checks, deployment readiness checks, notifications, triage, labeling, and routing.
- Pipeline triggers can now filter for specific states: failure, success, or cancellation.
- Conflict-detected and draft-to-ready triggers are enabled by default.
- A beta pattern-based approval tier lets developers approve repeated tool uses for an entire session instead of approving each invocation individually.
## Governance for Agents and Flows
- Instance administrators and top-level group owners gain controls over which AI content users can run.
- **Disable custom agents and flows** prevents users from creating or enabling custom-built content.
- **Restrict the AI Catalog to your group hierarchy** blocks AI Catalog items from outside the organization’s namespace, including community and third-party contributions.
- These controls help prevent unapproved agents and workflows from entering regulated or production environments.
## Pre-Save Flow Configuration Validation
- GitLab now validates AI Catalog flow configurations against the Duo Workflow Service before saving them.
- Errors such as missing inputs or invalid tool parameters appear directly in the UI.
- This moves troubleshooting to configuration time, reducing the risk of broken or overly active flows running in production.
## Approved AI Model Controls
- A public beta lets administrators define an allowlist of approved AI models.
- Organizations can also set an organization-wide default model.
- Teams retain flexibility within approved boundaries while meeting provider, compliance, or data-residency requirements.
- The first version applies to GitLab Duo Agentic Chat, with broader coverage planned.
Overall, GitLab 19.1 recommends treating AI workflows like production automation: trigger them from real events, validate them before deployment, and govern both the agents and models they use. Enterprises adopting the AI Catalog should configure the new restrictions and model policies before enabling widespread automated flows.
GitLab 19.1 presents a unified approach to application security and AI governance. It lets organizations enforce third-party SARIF-compatible scanners across every project, centralize findings, and automate remediation. At the same time, new AI governance features record agent activity and require approval for sensitive actions, enabling faster development without sacrificing accountability.
## Enforcing Complete Scanner Coverage
- Security scanners are often configured separately for each project, creating coverage gaps and policy drift.
- GitLab 19.1 allows administrators to enforce third-party scanners across all projects.
- SARIF-compatible scanner results flow into GitLab’s unified vulnerability view.
- Findings use the same governance and remediation workflows as GitLab-native results.
- GitLab Duo Agent Platform can:
- Triage findings with SAST False Positive Detection.
- Generate merge requests through Agentic SAST Vulnerability Resolution.
- Automatically remediate third-party scanner findings before production.
## Improving Secret Detection
- Secret detection now scans every commit on a newly created branch, rather than only the latest commit.
- This helps identify credentials introduced in earlier commits.
- Secret False Positive Detection, now generally available, provides:
- A confidence score for each finding.
- An explanation displayed in the vulnerability report.
- Developers can focus on genuine exposures instead of test credentials, placeholders, and example tokens.
## Governing AI Agent Actions
- AI coding agents can create merge requests, invoke tools, commit code, and modify projects.
- GitLab’s AI audit event streaming beta records every agent action and sends it to existing audit log destinations.
- Agent tool approval guardrails let administrators configure each tool to:
- Run automatically.
- Require human approval.
- Remain blocked.
- Sensitive operations, such as writing files or deleting resources, can therefore require explicit review.
- Approval decisions are also recorded, creating an auditable history for incident response and compliance.
## Governed Autonomy
GitLab’s overall goal is to combine autonomous development with enforceable controls. Organizations can prove scanner coverage, automate vulnerability remediation, restrict risky agent behavior, and review a complete audit trail of what agents did.
The practical recommendation is to centralize scanner governance and configure approval requirements for high-impact AI actions, allowing agents to work quickly while keeping security and accountability under human control.
GitLab 19.1, released June 18, 2026, focuses heavily on AI governance, security scanning, and compliance automation. The release adds AI-assisted false-positive detection for secrets, centralized controls for GitLab Duo, stronger approval guardrails for agents, and broader secret detection in feature branches. It also streamlines code review and compliance setup through automatic Code Owner assignment and framework templates.
## Security and Secret Detection
- **GitLab Duo secret false-positive detection** is generally available for Ultimate users.
- Automatically analyzes critical and high-severity secret detection findings after scans.
- Provides reasoning and confidence scores directly in vulnerability reports.
- Supports manual analysis from individual vulnerability pages.
- Helps security teams prioritize real threats and reduce alert fatigue.
- **Improved feature branch secret detection** scans every commit from the branch’s divergence point from the default branch through the latest commit.
- Previously, new branches or existing branches could leave secrets in earlier commits undetected.
- The broader scan helps identify leaked credentials before they reach shared branches or production.
## GitLab Duo Administration and AI Governance
- **Always-on availability mode** lets instance and top-level group administrators require GitLab Duo to remain enabled.
- Project, subgroup, and group owners cannot disable Duo when this policy is active.
- This complements the existing “always off” setting and supports centralized governance.
- **Tool approval guardrails for Duo agents** introduce three policy modes for individual tools:
- **Allow:** execute without user interaction.
- **Ask:** require inline human approval.
- **Deny:** block the tool entirely.
- Approval decisions generate audit events.
- The beta applies to Agentic Chat, IDE integrations, and flows.
- **Custom and external AI feature controls** allow administrators and top-level group Owners to:
- Prevent users from creating or enabling custom agents and flows.
- Block agents and flows owned outside the organization’s group hierarchy.
- **Custom flow YAML validation** checks configurations when flows are saved or updated.
- Errors such as missing inputs or invalid tool parameters are reported before runtime.
- This avoids discovering configuration problems only after a CI job begins.
- **Pattern-based tool approval for Agentic Chat** is also introduced in the Agentic Core updates, extending administrative control over how agent tools can be used.
## Code Review and Compliance
- **Automatic Code Owner reviewer assignment** removes the need to manually select reviewers for merge requests.
- GitLab assigns all Code Owners matching the changed files.
- Assignment occurs when a merge request is created as ready or when a draft becomes ready.
- Existing reviewer selections are preserved.
- **Compliance framework templates** are available in beta for Ultimate users.
- Teams can create frameworks from predefined requirements and controls.
- Templates can be previewed and customized before being applied.
- Nineteen templates are available, including ISO 27001:2022, SOC 2, FedRAMP, NIST, CIS, and TISAX.
## Contributor Recognition
- GitLab recognizes **Pishel65** as the month’s Notable Contributor.
- The Level 3 contributor had 19 merged merge requests and nine additional open merge requests since joining in October 2025.
GitLab 19.1 is particularly valuable for organizations adopting AI at scale: enable centralized Duo policies, require approval for sensitive agent actions, validate flows before execution, and use the expanded security and compliance features to reduce operational risk.
Runway Aleph 2.0 is now integrated into Figma Weave, giving creators precise, frame-level control over video edits. The model supports longer clips, reference images, and sequential creative decisions while preserving footage that users do not ask to change. It also enables substantial transformations—such as new camera angles, characters, or environments—without requiring a reshoot.
## More Time, More Control
- Aleph 2.0 supports video clips up to 30 seconds, allowing users to direct complete scenes.
- Reference images can guide the visual style and appearance of edits.
- Changes are applied across relevant frames while preserving unaffected elements.
- Subject-specific edits follow that subject throughout the footage.
## Sequenced Creative Workflows
- The Aleph 2.0 node in Figma Weave supports connected, step-by-step workflows.
- Creators can preview edits before committing them.
- Multiple decisions can be refined progressively rather than being forced into a single prompt.
- The workflow mirrors traditional creative development on a visual canvas.
## Extending Existing Footage
- Users can alter a scene beyond the limits of the original recording.
- Possible changes include:
- Adjusting the camera angle
- Adding new characters
- Transforming the environment
- Multiple creative directions can be explored side by side without restarting from scratch.
- The creator defines the desired conditions, while Aleph 2.0 generates the revised video.
## Pricing and Resources
- Figma says pricing will soon scale according to input length, potentially lowering costs for some use cases.
- Users can learn more through Figma’s help center, community templates library, and Weavy’s knowledge center.
Figma Weave users can use Aleph 2.0 to move from broad AI generation toward more controlled, iterative video direction—making it useful for experimentation, editing, and visual development without reshooting footage.
