标签：#Security

I built a small MCP server a while back — developer-presence , seven tools wrapping the GitHub REST API and the DEV.to API so an agent can check my repo stats, list my articles, or draft a new post without me leaving the chat. It's mine, I wrote every line, there's no third-party package doing anything sketchy under the hood. By the usual "vet your MCP servers before installing them" checklist, it passes clean. I've written that checklist article before. What I hadn't thought carefully about until recently is that vetting the server doesn't vet the data. Two of its tools go straight to the point: @mcp.tool () def get_repo_stats ( repo : str ) -> dict : """ Get stars, forks, watchers, open issues for enjoykumawat/<repo>. """ r = _gh ( f " /repos/ { GITHUB_USERNAME } / { repo } " ) return { " name " : r [ " name " ], " stars " : r [ " stargazers_count " ], " forks " : r [ " forks_count " ], " watchers " : r [ " watchers_count " ], " open_issues " : r [ " open_issues_count " ], " language " : r . get ( " language " ), " description " : r . get ( " description " ), } description is free text. Any repo owner can put anything in it. If I ever point this tool at a repo I don't control — someone else's fork, a dependency, anything — that field lands in my agent's context exactly the same way a trusted instruction would: as text in a tool result, with no marker distinguishing "this came from GitHub's database, unfiltered" from "this is something I told the agent to do." The server is safe. The channel is safe. The payload was never vetted at all, because there was nothing to vet — it's just whatever a stranger typed into a form. I only really felt this because of a task I run on a schedule: check dev.to for trending posts in a few tags, score them, and use the highest scorers as source material for what to write about next. Step one of that job is a loop over tag pages: for tag in [ " ai " , " llm " , " mcp " , " claudecode " , " agents " , " productivity " ]: url = f " http

Connecting an AI agent to a tool is becoming easier. Letting that agent operate a real business system responsibly is still a different problem. Imagine an existing commerce system with APIs for reading orders, changing inventory, creating refunds, and disabling staff accounts. OpenAPI can describe the endpoints. A tool protocol can make them discoverable. An agent framework can select an operation and generate arguments. But those pieces do not, by themselves, answer several business questions: Which operations may be exposed to an agent-facing surface? Which invocation must carry a trusted acting subject? Which operation is high consequence? When does an invocation express approval intent? Which calls need stronger audit handling? Which execution properties should a runtime know before it invokes the API? These questions sit between tool connectivity and final business authorization. That is the layer the Agent Capability Contract, or ACC, is designed to describe. Start with a concrete operation Consider this API operation: paths : /orders/{order_id}/refund : post : operationId : createRefund parameters : - in : path name : order_id required : true schema : type : string requestBody : required : true content : application/json : schema : type : object required : [ amount ] properties : amount : type : number minimum : 0 This is enough to describe how to call the operation. It is not enough to describe how an agent-facing system should treat it. ACC adds a small, machine-readable declaration next to the operation: x-agent-capability : version : 1 enabled : true scope : refund.create risk : level : high subject : required : true approval : required : true when : - param : amount op : " >" value : 1000 audit : sensitive : true execution : readonly : false idempotent : true timeout_ms : 10000 The declaration does not grant the refund. It tells a compatible runtime how the operation should be presented and governed before the business system receives the call. The miss

On 9 July 2026 the head of Windows published a post about AI-powered vulnerability discovery. One line in it was a warning to customers: "As AI helps defenders discover more issues, customers will see a higher volume of security updates included in each security release." It does not say how much higher. The post runs about 1400 words and contains no numbers at all. Five days later Microsoft shipped the July package: 1150 CVEs. The number Microsoft would not put in the blog post is sitting in Microsoft's own API. The Security Update Guide publishes every monthly package as machine-readable CVRF, acknowledgments included, no key required. So I pulled twelve months of it and did the arithmetic. What the data says I sampled eight months before the ramp and four after it. Month CVEs Month CVEs 2024-07 454 2026-04 737 2025-01 343 2026-05 991 2025-04 374 2026-06 1281 2025-07 527 2026-07 1150 2025-10 427 2026-01 310 2026-02 169 2026-03 460 The eight pre-ramp months average 383 CVEs. July 2026 is 1150, so the package is 3,0 times the old normal. The baseline broke in April and peaked in June at 1281. April to July inclusive is 4159 CVEs. At the old rate that is 10,9 months of output, delivered in four. The number I am not going to use February 2026 had 169 CVEs. It is the lowest month in two years, less than half the baseline. Divide July by February and you get 6,8 times, which is a much better number for a headline. I am not using it, because choosing your denominator is how honest people produce dishonest numbers. February is an outlier, and the only reason to anchor to it is that it flatters the story. The real multiplier is 3,0. It does not need help. It is not noise The obvious objection is that volume without quality is just a bigger pile. If AI were generating low-value findings that got patched anyway, the severity distribution would sag. It did the opposite. Measure 2025-07 2026-07 CVEs 527 1150 CVSS median 6,5 7,5 CVSS mean 6,47 7,26 CVSS 7,0 and above 48,0 % 71,

AI-assisted builders can take an idea from prompt to production in a weekend. That speed is useful, but it also compresses the part of the process where someone normally reviews deployment settings, browser-visible secrets, authorization boundaries, and recovery plans. A public security scanner is a good first pass for that problem. It is also easy to misunderstand. A clean public scan does not mean an application is secure, and a warning does not always mean a vulnerability is exploitable. The useful question is not “Did the scanner pass my app?” It is “What evidence could this scanner actually observe?” Layer 1: the public deployment surface A passive scanner can request the same resources that a normal visitor can reach. Depending on its scope, it may inspect: HTTP security headers such as Content-Security-Policy and Strict-Transport-Security HTTPS behavior and redirect consistency Public JavaScript bundles for credential-shaped strings Public source maps that expose original source structure Common sensitive paths such as environment files or repository metadata Cookie attributes and other response-level deployment signals These checks are valuable because they test the deployed result, not the configuration you intended to ship. For example, a repository may contain a CSP configuration while the CDN response does not. A source map may be disabled in one build configuration but still appear in production. A key may be stored safely on the server in most code paths while one client bundle accidentally contains a privileged token. The deployed surface is where those mistakes become observable. Layer 2: source-code review A public URL cannot reveal every control behind an application. Source review or SAST can inspect code paths, configuration, data flow, and dangerous implementation patterns that never appear in a normal response. This is where you can answer questions such as: Is authorization enforced on the server? Can a user change an object ID and read anothe

Why Pipelock Is an Egress Agent Firewall, Not an Inbound WAF The question behind the word firewall Security teams hear "firewall" and picture something inbound. A firewall, WAF, or IPS sits in front of a service. Traffic comes from the outside world toward the protected app. The control inspects requests before they reach the app and blocks malicious payloads at the door. That is outside-in protection. It fits web applications, where many attacks have recognizable request shapes: SQL injection, cross-site scripting, known exploit signatures, or malformed protocol behavior. The web server is the thing being attacked, and the attacker sends requests into it. AI agents invert that model. The agent is not only a server receiving input. It reads external content, calls tools, sends HTTP requests, invokes MCP servers, and runs with credentials. The dangerous event is rarely that a hostile packet reached the agent. The dangerous event is that the agent got talked into doing something with outbound effects. That is why Pipelock is built as an egress agent firewall, not a WAF-style inbound firewall. Why inbound filtering is the wrong primary model Prompt injection does not behave like a structured malware packet. It is natural-language instruction sitting in places the agent is supposed to read: a web page, a ticket, a search result, a tool response, an MCP server reply, or a user message. The channel is legitimate. The syntax is often normal. The attack is semantic and context-dependent. Solving that by filtering every input before it reaches the agent turns into an enumeration problem. You write patterns for "ignore previous instructions," then the attacker rephrases. You block one formatting trick, then the instruction is split across paragraphs, hidden in quoted text, encoded, or dressed up as policy text. Known phrases are worth catching, and Pipelock catches known injection markers in content it mediates, but input filtering cannot be the center of the security model.

The Hidden Cost of Manual IAM Review Most teams don't track how long they spend reviewing IAM policies. When I started measuring it on my own team, the numbers were worse than I expected. A thorough manual review of one IAM policy takes 10 to 15 minutes. Not a quick scan. A real review: read every statement, trace every cross-account trust, verify every condition key, check for privilege escalation paths, confirm the resource ARNs match what you think they should. At 4 engineers touching IAM once a week, that's 4 hours a month. 48 hours a year of senior engineers reading JSON documents. And that's the optimistic case. Add a security incident. Add an audit. Add the emergency Friday-afternoon policy change that needs review before deploy. The real number is higher. What manual review misses The problem isn't just the time. It's that humans are bad at repetitive structured-data review, especially under time pressure. Here are the things I've seen slip through manual IAM reviews on production systems: iam:PassRole with no condition. This is the big one. PassRole lets a principal pass a role to a service — and if there's no iam:PassedToService condition, that role can be passed to any service that accepts roles. Including services the attacker controls. The reviewer saw the action, mentally categorized it as "role stuff," and moved on. It was statement 47 of 52 — the reviewer had already been reading policies for 40 minutes. Wildcard resource with sensitive actions. s3:* on Resource: "*" is obvious. s3:GetObject on "arn:aws:s3:::*-backup/*" with a wildcard in the bucket name — that's subtle. The reviewer reads it as "restricted to backup buckets" and moves on. But the wildcard means any bucket ending in -backup , including ones in other accounts if cross-account access is configured. Missing aws:SourceArn on Lambda invocation permissions. When you grant another service permission to invoke your Lambda function, you need aws:SourceArn to prevent the confused deputy

Old and forgotten "shims" Microsoft failed to revoke have made Secure Boot bypasses simple.

Microsoft just released a long list of improvements for Windows 11 as part of its bigger patch Tuesdays, and that includes the ability to pause updates indefinitely, as reported earlier by Windows Central. This option rolled out to Windows Insiders earlier this year, allowing you to hold off on updates for up to 35 days […]

Microsoft Corp. today released software updates to plug at least 570 security holes in its Windows operating systems and other software, almost triple the number of vulnerabilities the software giant fixed in its record-smashing Patch Tuesday release last month. Microsoft attributed the burgeoning patch counts to vulnerability discoveries aided by artificial intelligence.

Introduction So imagine you are focused on your cappuccino-frappuccino doing something very important on you win laptop and then have a cringe attack due to the unknown Phone Link notification : Complete linking devices Your PC and mobile device are almost linked. Click here to continue linking devices. via Phone Link Then you switch off bluetooth, wifi, laptop - and you are right. What to do next ? Basic checks Settings -> Bluetooth & devices -> Mobile devices Settings -> Accounts -> Email & accounts Inspect recent notifications in Event Viewer eventvwr.msc Applications and Services Logs └ Microsoft └ Windows └ Notifications Applications and Services Logs └ Microsoft └ Windows └ Shell-Core Digital forensics Windows stores toast notifications in a local database, hence you need to install sqlite Get-ChildItem " $ env : LOCALAPPDATA \Microsoft\Windows\Notifications" output : Directory: C:\Users\$ USERNAME \A ppData \L ocal \M icrosoft \W indows \N otifications Mode LastWriteTime Length Name ---- ------------- ------ ---- d----- 1/1/2026 0:00 AM wpnidm -a---- 1/1/2026 0:00 AM 1000000 wpndatabase.db -a---- 1/1/2026 0:00 AM 10000 wpndatabase.db-shm -a---- 1/1/2026 0:00 AM 1000000 wpndatabase.db-wal wpndatabase.db is a SQLite database. connect to the database : sqlite3 " $env :LOCALAPPDATA \M icrosoft \W indows \N otifications \w pndatabase.db" query the Notification table . headers on . mode column SELECT Notification . Id , Notification . HandlerId , Notification . Type , Notification . ArrivalTime , Notification . Payload FROM Notification LIMIT 20 ; Then you will have something like : Id: [REDACTED] HandlerId: [REDACTED] Type: toast ArrivalTime: [REDACTED] Payload: <?xml version="1.0"?> <toast activationType= "protocol" launch= "ms-phone:fre/?cid=[REDACTED]&ref=FreIncompleteToast&reason=IncompleteNotificationsToast" > <visual> <binding template= "ToastGeneric" > <text hint-maxLines= "1" > Complete linking devices </text> <text> Your PC and mobile device are almost li

It's not abnormal for projects to go weeks, or dare I say months, between dependency updates. And when people finally do update, they do it in full force: everything at once, without checking anything. That habit has always carried risk, but in the new world of AI agents doing the updating, it collides head-on with a very real threat: supply chain attacks. The problem: install is an arbitrary code execution feature The package ecosystems we all depend on have spent the last few years demonstrating exactly how bad this can get. In September 2025, chalk and debug , part of a batch of eighteen packages with over two billion combined weekly downloads, started shipping a crypto-clipper after one maintainer's npm account was phished through a fake 2FA-reset email. Days later, the Shai-Hulud worm chewed through hundreds of packages on its own: its post-install script stole npm tokens from every machine it landed on and used them to publish more infected versions of itself. And a couple of weeks before either, the Nx compromise put a post-install payload on developer machines that prompted locally installed AI coding CLIs like Claude and Gemini to hunt down wallets and credentials for exfiltration. That last one should make every agent owner sit up straight: our own agents, conscripted as burglars. The pattern is consistent: a malicious version goes live, does its damage for a few hours or days, then gets caught and pulled. Based on this, I decided, not to do updates till a set of rules have been met. These rules, I have decided to burn them into Claude skills and let my agents deal with them. AI Agent Skills: paranoia as a config file In Claude Code, a skill is just a markdown file with instructions the agent loads when a task matches. This gives me way to encode my hard-won paranoia once and have it applied every single time , by something that never gets tired, never gets sloppy on a Friday afternoon, and never thinks "eh, it's probably fine." I wrote two of them, for no

The Iranian government exploited well-known flaws in cellphone networks to locate and then strike U.S. military personnel in the build-up and beginning of the war.

Telegram CEO Pavel Durov confirmed an outage in a tweet, saying that shortlinks to the messaging app had "stopped working."

Google and industry partners announced Agentic Resource Discovery (ARD) Specification, an open standard for publishing, discovering, and verifying AI tools, APIs, and agents. ARD introduces a discovery layer built on catalogs and registries, enabling dynamic capability discovery while leveraging existing protocols such as MCP and OpenAPI for execution and emphasizing trust and interoperability. By Leela Kumili

In today's mobile-first world, users expect authentication to be both secure and effortless. Typing passwords every time an app is opened not only impacts the user experience but also introduces security risks if passwords are weak or reused. Biometric authentication solves this problem by allowing users to verify their identity using Fingerprint , Face ID , Touch ID , Iris Scanner , or even their device's PIN/Password . If you're building a React Native application, @sbaiahmed1/react-native-biometrics is one of the most comprehensive biometric libraries available. Beyond simple authentication prompts, it offers hardware-backed cryptographic key management, biometric enrollment detection, device integrity checks, StrongBox support, and compatibility with both the React Native New Architecture and Expo. In this article, we'll explore everything this library offers and learn how to integrate biometric authentication into a React Native application. Why Biometric Authentication? Traditional authentication methods come with several drawbacks: Passwords are easy to forget. Weak passwords are vulnerable to attacks. OTP-based logins can be slow and frustrating. Users often abandon apps with poor login experiences. Biometric authentication addresses these challenges by providing: 🔒 Enhanced security ⚡ Faster authentication 😊 Better user experience 📱 Native platform support 🔑 Secure fallback using device credentials Whether you're building a banking app, healthcare platform, enterprise application, or e-commerce app, biometric authentication has become an expected feature. Installation Install the package using npm: npm install @ sbaiahmed1 /react-native-biometric s or with Yarn: yarn add @ sbaiahmed1 /react-native-biometric s For iOS: cd ios pod install Platform Configuration Before using biometric authentication, configure the required permissions for both Android and iOS. Android Open your android/app/src/main/AndroidManifest.xml file and add the following permissions: <

Many enterprise AI governance discussions start with frameworks. Frameworks are useful. They help organizations define principles, roles, controls and accountability. But when an enterprise starts using generative AI in real workflows, the practical governance problem often appears somewhere much more specific: the AI access path. That is the moment when an employee, application, copilot, agent or API workflow sends a request to an AI model. At that point, governance becomes operational. The practical governance questions Before an AI request reaches a model, an enterprise may need to answer several concrete questions: Who is sending the request? What business use case is involved? What data is being sent? Which AI model is being used? Is the model approved for this use case? Should sensitive data be masked or blocked? Was the access decision recorded? Can the activity be reviewed later? Can AI usage and token cost be explained by user, department, model and use case? These questions are not only policy questions. They are architecture questions. If the enterprise cannot answer them at the access path, AI governance may remain too far away from the real system behavior. Why the access path matters Many organizations already have AI policies. But policies are often written before or after the actual AI interaction. The access path is where policy meets execution. For example, a team may approve the use of generative AI for internal productivity. But the organization still needs to understand: whether customer data is being included in prompts; whether employees are using approved or unapproved models; whether sensitive content is being sent to external services; whether different departments are using AI in very different ways; whether audit evidence exists when an incident or review happens. This is why AI governance should not only be treated as a document, committee or training program. It also needs a technical control point. A simple access governance pattern A

✓ Human-authored analysis; AI used for formatting and proofreading. Scott Piper published a twenty-year retrospective on cloud security research in March 2026. It's the most useful structural history of the field I've seen — four eras, each with defining milestones, each with the tools and research that shaped cloud security. If you work in cloud security, read it first. What follows is a question about what the history reveals when you examine one detail it doesn't discuss. The four eras Piper divides two decades into four eras: 2006–2016, Foundational. Cloud providers built the security primitives — IAM (2011), CloudTrail (2013), Organizations and SCPs (2016). Before these existed, there was no mechanism for least privilege, no audit trail, and no organizational boundary. Security research in this era was part-time work from people with broader careers. 2016–2021, CSPM. Cloud security became a full-time job. CIS Benchmarks standardized what to check. Open-source tools proliferated — Prowler, CloudMapper, Pacu, Cloud Custodian, ScoutSuite. Cloud security during this time largely meant deploying a CSPM. 2021–2025, CNAPP. Point solutions gave way to platforms. Vendors integrated CSPM with container scanning, vulnerability management, and workload protection into a single product category. Research teams at vendors began finding cross-tenant vulnerabilities in the cloud providers themselves. 2025–present, AI. AI accelerates both attack and defense. Exploits that required deep language expertise are generated in minutes. A CTF challenge was solved by an AI within minutes of release. The industry is speed-running the cloud eras. This is a well-evidenced narrative. Every era is defined by a change in what tools could do and who was building them. The verb that didn't change Look at what each era's defining tools do. The direct action each tool performs on its direct object. In the CSPM era, the defining tools match API responses against rule databases. Prowler, ScoutSuit

Downloading an installer and immediately executing it as root collapses three operational decisions into one command: Which artifact? -> Did these bytes arrive intact? -> Should this host execute them? Separate those decisions and the install becomes reviewable, reproducible, and recoverable. A concrete source-review boundary At commit c58bcd4 , the MonkeyCode runner installation template selects x86_64 or aarch64 , checks AVX on x86, requires root, and downloads an architecture-specific installer before executing it. The reviewed template uses curl -4sSLk , so certificate verification is disabled by -k . It also downloads an unversioned path. I could not find a pinned version, digest, or signature check in that template. That is a statement about controls visible in one pinned file—not a claim that the release service is compromised or that no external release control exists. Put a manifest before execution For each release artifact, publish immutable metadata through a separately protected release process: { "version" : "1.2.3" , "architecture" : "x86_64" , "file" : "runner-installer-1.2.3-x86_64" , "sha256" : "<64 lowercase hex characters>" , "size" : 18439210 , "rollback" : { "previous_version" : "1.2.2" , "artifact" : "runner-installer-1.2.2-x86_64" } } SHA-256 detects bytes that differ from the manifest. It does not prove who authored the manifest. Serve the manifest over validated TLS, pin it through deployment configuration, or sign it and verify the signature with a trusted offline public key. Verify as an unprivileged staging step The companion verify-installer.mjs checks filename, exact size, digest, version, architecture, and rollback metadata: node verify-installer.mjs release-manifest.json fixture-installer.sh node test-verifier.mjs Expected output uses the fixture's actual digest: PASS 1.2.3-fixture sha256=<digest> PASS verified fixture; rejected tampered artifact before execution The negative test appends a line to the artifact and requires both size

Native XDP and generic SKB-mode XDP are not the same thing in practice. The same BPF program can pass the verifier and still behave differently depending on which mode the kernel uses, this could be a different verdict, different frame bytes, or different metadata. This post ships three things: an open differential test harness, a fixed eleven-packet corpus, and a simple way to classify the differences it finds. A tagged release lets anyone reproduce the virtio/veth baseline on Linux 6.8. The operational risk is straightforward. A firewall or rate-limiter validated only under native XDP can fall back to generic mode on an unsupported driver, a veth port, or after a reload. You keep the same bytecode, but behaviour can change, often without a clear error line. What this release includes: A harness loop: corpus → inject on the RX path → native vs generic sweep → xdpdump capture → compare.py manifest, comparing both the captured frame bytes and the XDP verdict ( PASS / DROP / TX / REDIRECT ). A deterministic corpus with eleven embedded test IDs ( 0xA001 – 0xA005 , 0xA007 – 0xA00C ; 0xA006 is intentionally omitted as a reserved gap in the generator). An operational divergence taxonomy (Class A / B / C). A virtio/veth smoke gate on Linux 6.8; now gating on frame bytes and verdict agreement that shows the full path is reproducible end to end. Scope for this post: native vs generic XDP on the virtio_vm profile only (five BPF programs, pinned manifests). This is part 1 of 2; it establishes the harness and an instrument-validity baseline; a follow-up post covers bare-metal divergence results. Physical NIC results are not part of this baseline. Ordinary conformance checks stop at “did the program load?” Differential testing asks a sharper question: given identical input packets, do the backends produce the same observable outcome at the hook? Background: native vs generic XDP Both modes load the same BPF object. They diverge at the hook point and in how the packet is represen

AudioTrust: reconciliar C2PA y watermark AudioSeal en audio sintético Un verificador local que lee las dos marcas de confianza de un audio generado por IA (procedencia C2PA + watermark AudioSeal) y emite un veredicto auditable sobre si coinciden, se contradicen o faltan. El problema Un audio sintético puede llevar dos marcas de confianza distintas: Procedencia C2PA : un certificado digital embebido en el archivo (su "DNI" de origen — quién, cuándo, con qué herramienta). Watermark AudioSeal : un código inaudible incrustado en el sonido, detectable aunque el audio se comparta o transcodifique. Cada una por separado es útil, pero ninguna es suficiente. La procedencia puede faltar (mucho audio generado no la incluye) y el watermark puede estar presente en audio totalmente legítimo. El caso interesante es cuando se contradicen : el manifest C2PA dice "grabado por un humano con una grabadora" pero el watermark de una herramienta de IA está presente. Eso es una señal de manipulación — el llamado Integrity Clash . AudioTrust no genera ni firma nada. Es un verificador : lee ambas capas y las reconcilia. Qué hace audio.wav ──► AudioTrust verify ──► veredicto + explicación C2PA watermark Veredicto ausente ausente unverifiable ausente presente partial origen sintético presente trusted origen humano presente contradiction (Integrity Clash) Salida JSON: { "file" : "audio.wav" , "verdict" : "trusted" , "c2pa" : { "present" : true , "source_type" : null , "claims" : [ "action=c2pa.created by TestTTS" , "generatedBy=TestTTS" ]}, "watermark" : { "present" : true , "detect_prob" : 0.92 }, "explanation" : "C2PA declara origen sintético y hay watermark fuerte: coherentes." } Cómo funciona Lectura C2PA con c2pa-python (el Reader de la librería oficial). Si no hay manifest, devuelve present=False sin crashear. Detección de watermark con audioseal . Devuelve solo detect_prob (P(audio watermarked) en [0,1]). Reconciliación determinista en reconcile.py . Dos decisiones de diseño que vale la