今日已更新 318 条资讯 | 累计 39011 条内容
关于我们

今日精选

HOT

最新资讯

共 39011 篇
第 1443/1951 页
开发者 InfoQ

Microsoft Scout, New Enterprise Autopilot Built on OpenClaw, Announced at Build 2026

Microsoft recently introduced at Build 2026 Microsoft Scout, an always-on agent. Scout belongs to a new category of agents Microsoft called Autopilots: always-on agents that work autonomously on a user’s behalf with their own identity, without needing to be prompted each time. Microsoft Scout integrates with Work IQ and is based on the open-source agent framework OpenClaw. By Bruno Couriol

Bruno Couriol 2026-06-18 13:26 14 原文
AI 资讯 Product Hunt

VELA

Securely execute AI-generated & untrusted code Discussion | Link

2026-06-18 13:10 6 原文
AI 资讯 Dev.to

I reverse-engineered my motorcycle's Bluetooth protocol to put Google Maps on the dashboard

My motorcycle has a Bluetooth instrument cluster. It pairs with the manufacturer's phone app and shows turn-by-turn navigation right on the dash, which sounds great until you actually use it. The nav is routed through a maps provider I don't love, the app is clunky, and there's no way to extend any of it. I kept thinking: it's just my bike talking to my phone over Bluetooth. How locked down can it really be? So one weekend I decided to find out, and a few weeks later I had Google Maps navigation running on the cluster through an app I wrote myself. Here's how that went. There are no docs Of course there aren't. It's a proprietary protocol, and the only reference that exists is the manufacturer's own app, in compiled form. So step one was just watching. I started with a GATT walk on the live bike, which is the Bluetooth equivalent of knocking on every door to see what's there. The cluster exposes one vendor service with two characteristics: one the phone writes to, one the bike sends notifications back on. That's the entire conversation surface. Then I captured the actual bytes going across. Android can log every Bluetooth packet through its HCI snoop log, so I paired the phone with the bike, rode around, and pulled the capture. Now I had real traffic, and absolutely no idea what any of it meant. Reading the app to read the protocol You can stare at hex forever and still guess wrong. The faster path was the app itself. I pulled the APK, ran it through JADX to decompile it, and got something close to readable source. Most of the class names weren't even obfuscated, which was a gift. From there it was cross-referencing: take a message I saw on the wire, find the code that builds it, and work out what each byte is. Frida helped a lot here. It lets you hook a running app and watch functions get called with their real arguments, so I could catch the exact moment the app turned "next turn is a left in 200m" into bytes and shipped them to the bike. Slowly the shape came out

Arjun 2026-06-18 11:41 17 原文
AI 资讯 Dev.to

LLM Prompt Injection & Guardrail Security

A recall reference built from working through a 7-layer prompt-injection challenge. Focus: how each defense layer works, where it breaks, and most importantly how to defend. The one idea underneath everything LLMs have no hard boundary between instructions and data . Everything in the context window — system prompt, user message, retrieved documents — is one stream of tokens the model interprets. Prompt injection exploits exactly this: attacker-controlled data gets read as instructions . You cannot fully filter your way out of it; you manage it with defense-in-depth , knowing each individual layer is bypassable. The defense layers (and where each cracks) A progression of controls from weakest to strongest, each with the lesson it teaches. 1–2. No / weak guardrails Baseline: the model just answers. Lesson: an LLM holding secrets in its context with no controls will leak them on request. 3. Input filtering — block words in the user's message Defense: scan the incoming prompt for banned terms ("code", "secret", "reveal") and block. Weakness: keyword blocklists are trivially evaded — synonyms, misspellings, split words, leetspeak, another language, oblique references. Filtering strings doesn't filter intent . What actually helps: prefer allowlists to blocklists; classify intent semantically rather than matching keywords; treat all input as untrusted; rate-limit and log probing. 4. Output filtering — catch the secret in the response Defense: string-match the known secret in the model's output and redact. Weakness: substring matching only catches the contiguous secret. Fragmenting or transforming it (separators, per-character, encodings) means the literal string never appears, so there is nothing to match. What actually helps: don't put secrets where the model can emit them in the first place; minimize sensitive data in context; treat output filtering as a brittle last line, never a primary control. 5. Input + output filtering combined Defense: both of the above, stacked.

Aaradhanah Appalo Eleven 2026-06-18 11:37 11 原文