标签：#ai

This interview has been lightly edited for length and clarity. Nick Statt: Hello and welcome to Decoder, Nilay’s show about big ideas and other problems. This is Nick Statt, senior producer. And I’m joined by our brand-new supervising producer, Greg Ott. Greg Ott: Good day, everyone. And Hi, Nilay. Nilay is here too. He is […]

n8n has introduced n8n Assistant , a preview chat-based builder that can plan, construct, test, and debug workflows directly in a user's n8n canvas. Its most consequential design choice is not simply the conversational interface. The assistant requests credentials only when they are needed, while credential access and workflow activation both require explicit user confirmation. For teams using automation to connect business systems, that creates a clearer boundary between AI assistance and actions that can affect live operations. According to n8n's official announcement , the workflows created through n8n Assistant are standard n8n workflows owned by the user. Credentials continue to be managed through n8n's usual credential screens rather than pasted into a chat. The feature also introduces a distinct consumption model: it uses AI credits allocated to the customer's plan, separately from the previous AI Workflow Builder. Credential controls are part of the workflow-building process The assistant is designed to help turn an automation request into a working workflow in the canvas. That can reduce the effort involved in assembling nodes, testing a workflow, and diagnosing problems. But n8n has placed approval gates around the actions with the greatest operational impact. The controls described for the preview include: Credentials are requested when needed , rather than collected before the assistant has reached the relevant step. Credentials are never exposed to the AI , according to n8n's documentation. Credential handling stays in standard credential screens , preserving the existing place where users manage connections. Workflow activation requires explicit confirmation , so the assistant cannot independently turn on an automation. Users own the resulting standard n8n workflows , rather than receiving a separate assistant-only format. This approach matters because a workflow can be harmless while it is being drafted but consequential once it starts reading data, s

In 1993, Jakob Nielsen wrote three numbers that have quietly governed every UI ever since. 0.1 second. 1 second. 10 seconds. Under 100 milliseconds, an interface feels instant. Under 1 second, thought doesn't break. Past 10 seconds, users are gone. Thirty-plus years later, those thresholds are still baseline material in every UX curriculum, and Nielsen Norman Group still publishes the same three cliffs when they're asked about response times. They map cleanly to the web. They map badly to voice. The missing screen is what breaks the mapping. Take away the loading spinner and every one of Nielsen's thresholds contracts. Nielsen's thresholds are neurological, not screen-based The numbers weren't invented for computers. Nielsen was consolidating perception research going back to the 1960s: Miller in 1968, Card and colleagues in 1991, all trying to pin down how long humans stay "in the loop" of an interaction. 100 ms : the ceiling for perceiving something as a direct response to your action. Below this, the effect feels like it belongs to you. Above it, cause and effect start to separate. 1 second : the ceiling for uninterrupted thought. Between 100 ms and 1 second, users notice the delay but stay in flow; past a second, they drop out of the task and start waiting. 10 seconds : the ceiling for holding attention at all. Past this, minds wander to email, phones, other tabs. The numbers describe human cognition, and the hardware they were measured on has changed beyond recognition without moving them. The 100 ms figure is unchanged in 2026. The 1-second figure still describes when a web page starts feeling broken. But those numbers assumed there was something to look at while you waited. Voice has no spinner Voice interfaces strip out the entire "we're working on it" channel. There is no loading bar. No skeleton state. No progress percentage. No "typing..." indicator sitting under the previous message. The only signal the user gets between "I stopped talking" and "the agen

I used to think that "optimization" meant staring at an EXPLAIN ANALYZE output until my eyes crossed, trying to guess which index the database optimizer was ignoring. I was wrong. Optimization isn’t about guessing; it’s about seeing the shape of your data before you even write a single line of application code. That’s why I built Code Architect Pro . It’s not a magic wand, but it is a pair of glasses for your database schema. The Problem with Raw Dumps We’ve all been there. You inherit a project, or you’re spinning up a new service, and you have a 500MB .sql dump file sitting on your desktop. You open it in VS Code, search for CREATE TABLE , and start mentally mapping out relationships. It’s tedious. It’s error-prone. And worst of all, it’s slow. Most developers treat SQL dumps as static archives. But they’re actually rich sources of architectural intent. The problem is that human brains are terrible at parsing thousands of lines of DDL (Data Definition Language) to spot normalization issues or missing foreign keys. We miss things. We assume an index exists because the column name looks like it should be indexed, not because it actually is. I wanted a tool that could read that dump instantly and tell me: "Hey, this table has a 1-to-1 relationship with that one, and you’re missing a composite index on these two columns." How It Runs Locally This is the part that surprised me most during development. I didn’t build a cloud backend to process these files. Privacy is huge when you’re dealing with schema definitions that might contain sensitive column names or proprietary table structures. So, Code Architect Pro runs entirely in your browser. It uses a private on-device AI engine to parse the raw SQL text. When you upload a file, nothing leaves your computer. The parsing, the graph generation, and the suggestion engine all happen locally. This means two things: Speed: There’s no network latency waiting for a server to spin up. The analysis is near-instant because it’s ju

The buzzy startup raised $600 million in its Series C round.

A file gets hashed. The hash goes off to get anchored. Sometime later, a webhook arrives saying the anchor is done. That gap between "submitted" and "confirmed" is where most of the hard problems in an async proof pipeline actually live. Not the hashing. Not the anchoring. The webhook. I hit this building the anchoring flow behind ProofLedger, and it's a pattern that applies to any system where a client kicks off work and gets notified later: payment confirmations, video transcoding, background exports. If you're building or consuming webhooks for anything time-sensitive, these four problems show up in the same order every time. Verify the signature before you trust the payload A webhook endpoint is a URL on the open internet. Anyone can POST to it. If your handler reads status: "anchored" from the body and acts on it without checking where it came from, you've built an endpoint that lets a stranger fake completion events. The standard fix is HMAC-SHA256. The sender computes a signature over the raw request body using a shared secret, puts it in a header, and the receiver recomputes it and compares. import hashlib import hmac from flask import Flask , request , abort app = Flask ( __name__ ) WEBHOOK_SECRET = b " shared-secret-from-sender " def verify_signature ( payload_body : bytes , signature_header : str ) -> bool : expected = hmac . new ( WEBHOOK_SECRET , payload_body , hashlib . sha256 ). hexdigest () return hmac . compare_digest ( expected , signature_header ) @app.route ( " /webhooks/proof-status " , methods = [ " POST " ]) def handle_webhook (): signature = request . headers . get ( " X-Signature-256 " , "" ) if not verify_signature ( request . get_data (), signature ): abort ( 401 , " invalid signature " ) event = request . get_json () process_event ( event ) return "" , 204 Two details matter here and both are easy to get wrong. First, hmac.compare_digest instead of == . A regular string comparison short-circuits on the first mismatched byte, which leaks t

If your threat model for a frontier LLM didn't include "nation-state actors scraping your chain-of-thought at industrial scale via bulk API subscriptions," it does now. Context This isn't a novel attack category. It's the AI-era version of something security teams have watched for two decades: scraping, credential stuffing, proxy-hopping, ToS abuse, all repurposed against a new kind of asset. What's different is the target. We're not talking about someone ripping off pricing data or scraping a job board. NSA, CISA, and the FBI are now saying that entire reasoning traces from Claude, GPT, Gemini, and Grok, the actual chain-of-thought outputs that represent enormous R&D investment, are being harvested at scale to train competing models elsewhere. The mechanics described (automated failover, distributed infrastructure, obfuscated accounts, bulk subscription abuse) are boringly familiar. This is the same playbook used against ticketing sites and ad networks for years. The novelty isn't the technique. It's that the thing being stolen is a model's reasoning process, and the buyer is allegedly a state-linked AI industry racing to close a capability gap. Hype Check Here's where I'd slow down before treating this as a five-alarm fire or a footnote. Overstated: the framing that this is some brand-new, sophisticated attack vector that caught everyone off guard. It didn't. API abuse, proxy laundering, and subscription farming are known problems with known (if imperfect) mitigations. Calling it "industrial-scale distillation" makes it sound like a new discipline of espionage. It's rate-limit evasion with better funding. Understated: how structurally hard this is to actually stop. You can rate-limit a single account. You can't easily rate-limit a well-resourced adversary running thousands of accounts across distributed infrastructure with automated failover, especially when the product being abused is intentionally optimized for high-volume, low-friction API access. Every lever a

Tern has described its tech as "Google Maps for the battlefield."

Give an AI agent a mere rumor of an exploit, and it’s enough for them to find it. What’s worse, I found I could use my own agents to find the exploit just by knowing roughly what it was about and so could have been exploiting it well before the public patch was available! Given that just the rumour of a security issue seems enough to give attackers enough info to find new exploits, we’re going to need to change the way we deal with security responses in open source. Simon Willison comments : Anil points out that this rate of discovery appears incompatible with existing open source embargo practices for new issues. If an issue can become an exploit this fast, we need to figure out new processes for keeping our communities safe...

AI pentesting tools are changing how organizations validate security weaknesses. Instead of relying only on periodic manual assessments or vulnerability scanners, security teams can now use autonomous or agentic systems to test applications, APIs, infrastructure, identity, and cloud environments more frequently. The strongest platforms go beyond detection. They attempt exploitation, verify findings, reproduce attack paths, and help teams confirm remediation worked. But these products are not interchangeable. Some focus on applications and APIs. Others specialize in infrastructure, identity, cloud, or broader adversarial exposure validation. Here are six of the strongest AI pentesting platforms to consider in 2026: Aikido Security XBOW Terra Security Horizon3.ai NodeZero Pentera Cobalt AI Pentesting Tools at a Glance Tool Best Fit Testing Approach Main Strength Aikido Security Enterprises focused on application and API security Autonomous AI pentesting White box testing, verified findings, enterprise controls, broader AppSec context XBOW Organizations prioritizing autonomous application testing Autonomous AI agents Exploit validation and autonomous application testing Terra Security Enterprises wanting continuous agentic testing with human oversight Agentic testing with human governance Web, AI, external network, and emerging internal network coverage Horizon3.ai NodeZero Enterprises validating infrastructure and attack paths Autonomous pentesting Identity, infrastructure, cloud, web application, and attack path validation Pentera Large enterprises running continuous exposure validation Automated adversarial testing Broad infrastructure, cloud, identity, and external exposure validation Cobalt Organizations wanting AI-based scale plus human pentesting expertise AI testing directed by human pentesters Application coverage, PTaaS, and compliance-oriented human testing What Is an AI Pentesting Tool? An AI pentesting tool uses AI agents, automated attack logic, or both t

This is what our MCP endpoint returned to a client speaking JSON-RPC: HTTP / 2 403 content-type : text/html; charset=UTF-8 server : cloudflare Attention Required! | Cloudflare Please enable cookies. Sorry, you have been blocked A program was being asked to enable cookies. We did not see that for three days, because that is not what the client reported. The client reported a parse failure, and a parse failure points at your own serialization, not at a machine four thousand kilometres away. What it looked like from inside The connector could not talk to our server. The tools never listed. Everything we could check on our side looked correct: valid JSON-RPC, right content type, right status codes, protocol revision we support. So we did the reasonable thing and started fixing the things that were wrong but adjacent. GET /{prefix}/_mcp was returning JSON. Per the Streamable HTTP spec it should return 405 if the server does not offer an SSE stream on GET. We changed it. It is a real fix and we kept it. It changed nothing. That is the value of shipping one variable at a time. If we had bundled that change with anything else, the next result would have been unreadable. The thing that actually settled it We wrote a minimal MCP server that imitated our own response shape exactly: application/json on POST, 405 on GET. A hundred lines, no auth, no database, nothing of ours in it. Then we exposed it through an ngrok tunnel and pointed the same connector at it. It worked immediately. Tools listed, first try. That one result eliminated most of the search space. Our response shape was fine, because a server with the same shape worked. The protocol was fine. The connector was fine. What was left was everything between the connector and our application, which is exactly the part we had not been looking at, because it is not in the repository. If you take one thing from this: when you cannot find the bug in your code, build something that cannot possibly contain it and see whether th

Functional tests passing is not the same as code being safe to ship. Here is a reproducible case: an AI-generated login endpoint that behaves correctly, the scan finding I checked before launch, and the fix that made the pattern disappear. The code runs, but I would not ship it like this This is a local demo equivalent of a login endpoint, not live production code and not a client project: username = request . form . get ( " username " , "" ) password = request . form . get ( " password " , "" ) sql = f " SELECT id FROM users WHERE username = ' { username } ' AND password = ' { password } '" cursor . execute ( sql ) row = cursor . fetchone () if row : return { " ok " : True } return { " ok " : False }, 401 It works: correct credentials return success. My concern is not whether it works today. It is that username and password come from an HTTP request and are placed directly inside an SQL string. A first-pass scan finds the pattern to check I did not read every line first. I ran a local quick scan: code-audit app --format html --output report.html One result was: Severity Rule Risk Location High sql-concat SQL assembled from strings, user input can reach the query app/login.py:12 A high finding is not an automatic conclusion. I confirm it in four steps. 1. Where does the input come from? username and password come from request.form . That means a client can submit arbitrary values. Input from HTTP requests is untrusted by default. 2. Where does it go? The values skip length checks, type checks, escaping and parameterization, then enter the SQL template: sql = f " SELECT id FROM users WHERE username = ' { username } ' AND password = ' { password } '" cursor . execute ( sql ) The source is a request parameter. The sink is SQL execution. There is no boundary between them. 3. Can it be exploited? I do not attack my own project. I reason through SQL syntax: If username contains: ' OR '1'='1 the resulting SQL can become: SELECT id FROM users WHERE username = '' OR '1' = '1

Generated media needs a release record just as much as application code does. When a team cannot tell which script produced an audio file, or which approved offer belongs to an image, the problem usually appears during review rather than generation. Disclosure: This article was created with AI assistance. It describes a proposed engineering workflow, not measured results from a production deployment. I am an independent ElevenLabs and AdCreative.ai affiliate; the optional links at the end may earn me a commission. Make the asset, not the generation request, your unit of review A successful request only tells you that a service returned something. It does not establish that the result is suitable to publish. For audio, a reviewer might need to check the spoken numbers, names, pauses, and the correspondence between the audio and its transcript. For an ad image, the reviewer might need to check the product appearance, exact offer, legibility, and destination page. Both workflows benefit from the same separation: Produce a candidate. Record what went into it. Review the candidate in its intended context. Approve one exact artifact. Publish that artifact and retain a rollback reference. Avoid a single done flag. A candidate can be generated but still awaiting review; a reviewed artifact can later be superseded. Keep a small manifest beside each export Here is an illustrative record for a tutorial voiceover. The identifiers are examples, not real provider credentials or a vendor API schema. { "asset_id" : "onboarding-en-voice-004" , "kind" : "audio" , "source_revision" : "script-004" , "generation_config_revision" : "voice-settings-002" , "artifact_path" : "exports/onboarding-en-voice-004.mp3" , "artifact_sha256" : null , "status" : "review_pending" , "reviewed_by" : null , "approved_at" : null , "supersedes" : "onboarding-en-voice-003" } Populate the hash from the actual exported bytes. Leave approval fields empty until review has happened. A placeholder such as null is

DeepSeek-native terminal coding agent; /ship one sentence → verified code. 0.22.1: grill card wraps long questions fully (no 2-line ellipsis clip); sync dsh packages to 0.1.5-rc.1 Install: npm i -g @deepseek-ai/dsh codsh-cli && codsh Links: GitHub · Docs · npm codsh-cli Not a Claude Code env wrapper. Feedback and a star are always appreciated.

🪐 Smart Wallet Terminal Track influencers, smart-money wallets, top profit leaders, and whales from one animated terminal dashboard. Features • Quick Start • Controls • Project Structure • Guides • Disclaimer 📟 Overview ** Smart Wallet Terminal** is a Python terminal application that transforms 's smart-money wallet feeds into a live, keyboard-controlled market intelligence dashboard. The interface is designed around the visual language of professional financial terminals: High-density wallet tables Bright market-status colors Animated loading and printing effects Live profit-and-loss indicators Wallet ranking and activity analysis Fast keyboard navigation Automatic data synchronization Compact 24-hour market statistics The project is intended for wallet discovery, market research, activity monitoring, and educational analysis. It is not a trading bot and does not execute transactions. ✨ Features 🧠 Four Wallet Intelligence Channels Channel API Category Purpose Influencers influencer Tracks wallets associated with public social identities Smart Money smartMoney Surfaces wallets classified as sophisticated market participants Top PNL topPnl Ranks wallets by recent realized or calculated profit performance Whales whale Highlights large and highly active market participants 📊 Live Terminal Metrics The dashboard displays: Wallet rank Twitter or X username when available Shortened wallet address 24-hour PNL in USD 24-hour trading volume Transaction count Win rate Last activity time Aggregate channel PNL Aggregate volume Aggregate transactions Average win rate PNL distribution sparkline API cache timestamp Current sorting mode Search filter state Synchronization status ⚡ Interactive Experience Parallel API requests across all four categories Non-blocking terminal rendering Automatic refresh every 45 seconds Manual refresh support Animated boot sequence Progressive status-message printing Progressive wallet-row reveal Keyboard-only navigation Full-screen alternate terminal

AI Dev Weekly is a Thursday series where I cover the week's most important AI developer news, with my take as someone who actually uses these tools daily. Four different layers of the agent stack changed this week. OpenAI introduced GPT-6 Astra for the hardest tool-rich work. Google made its Kotlin agent framework production-ready. GitHub gave enterprise administrators permissions that local settings cannot weaken. And NVIDIA released a local inference router that spreads independent agent calls across computers you already own. 1. GPT-6 Astra raises the ceiling and the bill OpenAI introduced GPT-6 Astra as its highest-capability model for complex reasoning, coding, computer use, research, and document creation. The API model ID is gpt-6-astra , with a 1,050,000-token context window, 128,000 maximum output tokens, and low through max reasoning levels. The official model guide adds three API capabilities that matter more than another benchmark table: asynchronous tool calls , so the model can continue independent work while your application runs a slow tool; mid-turn steering over a WebSocket connection, preserving completed work when requirements change; reasoning updates without breaking the prompt cache , using a configuration_update item to change effort during a conversation. These features are aimed at long-running systems, not one-shot chat. Async tools require the application to track pending calls and return results with the original call ID. Mid-turn steering needs event handling that distinguishes new instructions from tool results. Neither feature makes concurrency safe automatically. Standard pricing is $10 per million input tokens, $1 per million cached input tokens, and $50 per million output tokens . Cache writes cost $12.50 per million. Batch and Flex are half the standard rates, while Fast mode is twice the standard price. There is also a long-context cliff. Requests above 272,000 input tokens charge the full request at 2x input and cache rates and

Originally published on gkosmo.eu . An agent is a background job that gets to call a few methods I have been putting this post off for months. Partly because "AI agents" is a phrase that makes me tired, and partly because most of what I read about it is either a demo that writes haikus or an architecture diagram with eleven boxes. Here is what I actually run. It's small. You can paste it into a Rails app this afternoon. The gems are rcrewai and rcrewai-rails . I maintain both and I use them on nakyma.io , so this is not a neutral review. It is the thing I reach for. The example A shop. Customers open support tickets. Somebody in the shop reads each one, looks up the customer's orders, decides if it's a refund, a shipping question or something else, and writes a reply. That last person is the bottleneck. We are going to replace the reading and the drafting, and keep the sending. That line matters: agents draft, humans send. Every time I've skipped this rule I regretted it within a week. Setup # Gemfile gem "rcrewai" gem "rcrewai-rails" # config/initializers/rcrewai.rb RCrewAI . configure do | config | config . llm_provider = :anthropic config . anthropic_api_key = ENV . fetch ( "ANTHROPIC_API_KEY" ) config . anthropic_model = ENV . fetch ( "ANTHROPIC_MODEL" , "claude-sonnet-4-5" ) config . temperature = 0.1 end Temperature low. This is a support desk, not a poetry slam. The tool This is the part people get wrong, so it comes first. A tool is a Ruby object the model is allowed to call. Not "the database". Not "ActiveRecord". One method, scoped to one customer, read-only, returning a string. # app/tools/order_lookup_tool.rb class OrderLookupTool < RCrewAI :: Tools :: Base tool_name "order_lookup" description "Recent orders for the customer who opened this ticket. " \ "Returns number, status, total and shipped_at." param :limit , type: :integer , required: false , default: 5 , description: "How many recent orders to return (max 10)" def initialize ( customer :) super ()

AI coding assistants have become a core part of software development. AI-generated code has shown productivity gains, but it's also contributing to security weaknesses and familiar bug patterns. In this article, author Nitin Garg highlights the bottleneck has moved from code generation to code verification, and how to detect & mitigate it when the AI-generated behavior diverges from the intent. By Nitin Garg

OpenAI and GSA will offer eligible federal, state, local, and tribal governments $0 license fees, 50% off usage, and expanded cyber defense support.

Adding a second agent creates a coordination problem before it creates a capability gain. Someone must define the assignment, preserve the relevant context, reconcile the result and decide whether another attempt is allowed. Those obligations exist even when the second agent produces nothing useful. The title describes that architectural asymmetry, not a universal measured growth rate: extra capability is possible, but it has to earn the machinery introduced to obtain it. Start with a working single-agent baseline. Split one part only when you can name the missing capability, state the boundary of the delegated task and verify the returned artifact. This article develops a coordination-budget table and a handoff contract for that decision. Its examples and numbers are hypothetical; they are not results from a benchmark or a client deployment. AI assisted the drafting and the conceptual cover. Define the result before multiplying the workers A system becomes more capable when it completes a useful job that the baseline cannot complete reliably, or achieves an agreed outcome within a better operating constraint. More messages, more tool calls and a longer final answer do not establish that improvement. The unit of value belongs to the user: a resolved support case, an accepted code change or a decision supported by the required evidence. Consider a support workflow that proposes an account adjustment. It reads a customer's request, retrieves the applicable policy and prepares a recommendation for an authorized operator. Success means the recommendation matches the relevant account facts and policy version, contains the required evidence and leaves the adjustment untouched until the authorized action. A persuasive explanation attached to the wrong account is a failure. The baseline could be one agent with retrieval and a narrowly defined set of read-only tools. It might already have several model calls, retries and deterministic checks. Single-agent does not mean one p