AI

In this tutorial, we explore how to run OpenAI’s open-weight GPT-OSS models in Google Colab with a strong focus on their technical behavior, deployment requirements, and practical inference workflows. We begin by setting up the exact dependencies needed for Transformers-based execution, verifying GPU availability, and loading openai/gpt-oss-20b with the correct configuration using native MXFP4 quantization, torch.bfloat16 activations. As we move through the tutorial, we work directly with core capabilities such as structured generation, streaming, multi-turn dialogue handling, tool execution patterns, and batch inference, while keeping in mind how open-weight models differ from closed-hosted APIs in terms of transparency, controllability, memory constraints, and local execution trade-offs. Also, we treat GPT-OSS not just as a chatbot, but as a technically inspectable open-weight LLM stack that we can configure, prompt, and extend inside a reproducible workflow. Copy CodeCopiedUse a different Browser print(” Step 1: Installing required packages…”) print(“=” * 70) !pip install -q –upgrade pip !pip install -q transformers>=4.51.0 accelerate sentencepiece protobuf !pip install -q huggingface_hub gradio ipywidgets !pip install -q openai-harmony import transformers print(f” Transformers version: {transformers.__version__}”) import torch print(f”n System Information:”) print(f” PyTorch version: {torch.__version__}”) print(f” CUDA available: {torch.cuda.is_available()}”) if torch.cuda.is_available(): gpu_name = torch.cuda.get_device_name(0) gpu_memory = torch.cuda.get_device_properties(0).total_memory / 1e9 print(f” GPU: {gpu_name}”) print(f” GPU Memory: {gpu_memory:.2f} GB”) if gpu_memory < 15: print(f”n WARNING: gpt-oss-20b requires ~16GB VRAM.”) print(f” Your GPU has {gpu_memory:.1f}GB. Consider using Colab Pro for T4/A100.”) else: print(f”n GPU memory sufficient for gpt-oss-20b”) else: print(“n No GPU detected!”) print(” Go to: Runtime → Change runtime type → Select ‘T4 GPU'”) raise RuntimeError(“GPU required for this tutorial”) print(“n” + “=” * 70) print(” PART 2: Loading GPT-OSS Model (Correct Method)”) print(“=” * 70) from transformers import AutoModelForCausalLM, AutoTokenizer, pipeline import torch MODEL_ID = “openai/gpt-oss-20b” print(f”n Loading model: {MODEL_ID}”) print(” This may take several minutes on first run…”) print(” (Model size: ~40GB download, uses native MXFP4 quantization)”) tokenizer = AutoTokenizer.from_pretrained( MODEL_ID, trust_remote_code=True ) model = AutoModelForCausalLM.from_pretrained( MODEL_ID, torch_dtype=torch.bfloat16, device_map=”auto”, trust_remote_code=True, ) pipe = pipeline( “text-generation”, model=model, tokenizer=tokenizer, ) print(” Model loaded successfully!”) print(f” Model dtype: {model.dtype}”) print(f” Device: {model.device}”) if torch.cuda.is_available(): allocated = torch.cuda.memory_allocated() / 1e9 reserved = torch.cuda.memory_reserved() / 1e9 print(f” GPU Memory Allocated: {allocated:.2f} GB”) print(f” GPU Memory Reserved: {reserved:.2f} GB”) print(“n” + “=” * 70) print(” PART 3: Basic Inference Examples”) print(“=” * 70) def generate_response(messages, max_new_tokens=256, temperature=0.8, top_p=1.0): “”” Generate a response using gpt-oss with recommended parameters. OpenAI recommends: temperature=1.0, top_p=1.0 for gpt-oss “”” output = pipe( messages, max_new_tokens=max_new_tokens, do_sample=True, temperature=temperature, top_p=top_p, pad_token_id=tokenizer.eos_token_id, ) return output[0][“generated_text”][-1][“content”] print(“n Example 1: Simple Question Answering”) print(“-” * 50) messages = [ {“role”: “user”, “content”: “What is the Pythagorean theorem? Explain briefly.”} ] response = generate_response(messages, max_new_tokens=150) print(f”User: {messages[0][‘content’]}”) print(f”nAssistant: {response}”) print(“nn Example 2: Code Generation”) print(“-” * 50) messages = [ ] response = generate_response(messages, max_new_tokens=300) print(f”User: {messages[0][‘content’]}”) print(f”nAssistant: {response}”) print(“nn Example 3: Creative Writing”) print(“-” * 50) messages = [ {“role”: “user”, “content”: “Write a haiku about artificial intelligence.”} ] response = generate_response(messages, max_new_tokens=100, temperature=1.0) print(f”User: {messages[0][‘content’]}”) print(f”nAssistant: {response}”) We set up the full Colab environment required to run GPT-OSS properly and verify that the system has a compatible GPU with enough VRAM. We install the core libraries, check the PyTorch and Transformers versions, and confirm that the runtime is suitable for loading an open-weight model like gpt-oss-20b. We then load the tokenizer, initialize the model with the correct technical configuration, and run a few basic inference examples to confirm that the open-weight pipeline is working end to end. Copy CodeCopiedUse a different Browser print(“n” + “=” * 70) print(” PART 4: Configurable Reasoning Effort”) print(“=” * 70) print(“”” GPT-OSS supports different reasoning effort levels: • LOW – Quick, concise answers (fewer tokens, faster) • MEDIUM – Balanced reasoning and response • HIGH – Deep thinking with full chain-of-thought The reasoning effort is controlled through system prompts and generation parameters. “””) class ReasoningEffortController: “”” Controls reasoning effort levels for gpt-oss generations. “”” EFFORT_CONFIGS = { “low”: { “system_prompt”: “You are a helpful assistant. Be concise and direct.”, “max_tokens”: 200, “temperature”: 0.7, “description”: “Quick, concise answers” }, “medium”: { “system_prompt”: “You are a helpful assistant. Think through problems step by step and provide clear, well-reasoned answers.”, “max_tokens”: 400, “temperature”: 0.8, “description”: “Balanced reasoning” }, “high”: { “system_prompt”: “””You are a helpful assistant with advanced reasoning capabilities. For complex problems: 1. First, analyze the problem thoroughly 2. Consider multiple approaches 3. Show your complete chain of thought 4. Provide a comprehensive, well-reasoned answer Take your time to think deeply before responding.”””, “max_tokens”: 800, “temperature”: 1.0, “description”: “Deep chain-of-thought reasoning” } } def __init__(self, pipeline, tokenizer): self.pipe = pipeline self.tokenizer = tokenizer def generate(self, user_message: str, effort: str = “medium”) -> dict: “””Generate response with specified reasoning effort.””” if effort not in self.EFFORT_CONFIGS: raise ValueError(f”Effort must be one of: {list(self.EFFORT_CONFIGS.keys())}”) config = self.EFFORT_CONFIGS[effort] messages = [ {“role”: “system”, “content”: config[“system_prompt”]}, {“role”: “user”, “content”: user_message} ] output = self.pipe( messages, max_new_tokens=config[“max_tokens”], do_sample=True, temperature=config[“temperature”], top_p=1.0, pad_token_id=self.tokenizer.eos_token_id, ) return { “effort”: effort, “description”: config[“description”], “response”: output[0][“generated_text”][-1][“content”], “max_tokens_used”: config[“max_tokens”] } reasoning_controller = ReasoningEffortController(pipe, tokenizer) print(f”n Logic Puzzle: {test_question}n”) for effort in [“low”, “medium”, “high”]: result = reasoning_controller.generate(test_question, effort) print(f”━━━ {effort.upper()} ({result[‘description’]}) ━━━”) print(f”{result[‘response’][:500]}…”) print() print(“n” + “=” * 70) print(” PART 5: Structured Output Generation (JSON Mode)”) print(“=” * 70) import json import re class StructuredOutputGenerator: “”” Generate structured JSON outputs with schema validation. “”” def __init__(self, pipeline, tokenizer): self.pipe = pipeline self.tokenizer = tokenizer def generate_json(self, prompt: str, schema: dict, max_retries: int = 2) -> dict: “”” Generate JSON output in accordance with a specified schema. Args: prompt: The user’s request schema: JSON schema description max_retries: Number of retries on parse failure “”” schema_str = json.dumps(schema, indent=2) system_prompt = f”””You are a helpful assistant that ONLY outputs valid JSON. Your response must exactly match this JSON schema: {schema_str} RULES: – Output ONLY the JSON object, nothing else – No markdown code blocks (no “`) – No explanations before or after – Ensure all required fields are present – Use correct data types as specified””” messages = [ {“role”: “system”, “content”: system_prompt}, {“role”: “user”, “content”:

Table of contents What Is AI Red Teaming? Top 19 AI Red Teaming Tools (2026) Conclusion What Is AI Red Teaming? AI Red Teaming is the process of systematically testing artificial intelligence systems—especially generative AI and machine learning models—against adversarial attacks and security stress scenarios. Red teaming goes beyond classic penetration testing; while penetration testing targets known software flaws, red teaming probes for unknown AI-specific vulnerabilities, unforeseen risks, and emergent behaviors. The process adopts the mindset of a malicious adversary, simulating attacks such as prompt injection, data poisoning, jailbreaking, model evasion, bias exploitation, and data leakage. This ensures AI models are not only robust against traditional threats, but also resilient to novel misuse scenarios unique to current AI systems. Key Features & Benefits Threat Modeling: Identify and simulate all potential attack scenarios—from prompt injection to adversarial manipulation and data exfiltration. Realistic Adversarial Behavior: Emulates actual attacker techniques using both manual and automated tools, beyond what is covered in penetration testing. Vulnerability Discovery: Uncovers risks such as bias, fairness gaps, privacy exposure, and reliability failures that may not emerge in pre-release testing. Regulatory Compliance: Supports compliance requirements (EU AI Act, NIST RMF, US Executive Orders) increasingly mandating red teaming for high-risk AI deployments. Continuous Security Validation: Integrates into CI/CD pipelines, enabling ongoing risk assessment and resilience improvement. Red teaming can be carried out by internal security teams, specialized third parties, or platforms built solely for adversarial testing of AI systems. Top 19 AI Red Teaming Tools (2026) Below is a rigorously researched list of the latest and most reputable AI red teaming tools, frameworks, and platforms—spanning open-source, commercial, and industry-leading solutions for both generic and AI-specific attacks: Mindgard – Automated AI red teaming and model vulnerability assessment. MIND.io – Data security platform providing autonomous DLP and data detection and response (DDR) for Agentic AI. Garak – Open-source LLM adversarial testing toolkit. HiddenLayer– A comprehensive AI security platform that provides automated model scanning and red teaming. AIF360 (IBM) – AI Fairness 360 toolkit for bias and fairness assessment. Foolbox – Library for adversarial attacks on AI models. Penligent– An AI-powered penetration testing tool that requires no expert knowledge Giskard– Comprehensive testing for traditional Machine Learning models and Agentic AI Adversarial Robustness Toolbox (ART) – IBM’s open-source toolkit for ML model security. FuzzyAI– A powerful tool for automated LLM fuzzing DeepTeam– An AI framework to red team LLMs and LLM systems SPLX– A unified platform to test, protect & govern AI at scale Pentera– A Platform that executes AI-driven adversarial testing in production to validate exploitability, prioritize remediation. Dreadnode – ML/AI vulnerability detection and red team toolkit. Galah – AI honeypot framework supporting LLM use cases. Meerkat – Data visualization and adversarial testing for ML. Ghidra/GPT-WPRE – Code reverse engineering platform with LLM analysis plugins. Guardrails – Application security for LLMs, prompt injection defense. Snyk – Developer-focused LLM red teaming tool simulating prompt injection and adversarial attacks. Conclusion In the era of generative AI and Large Language Models, AI Red Teaming has become foundational to responsible and resilient AI deployment. Organizations must embrace adversarial testing to uncover hidden vulnerabilities and adapt their defenses to new threat vectors—including attacks driven by prompt engineering, data leakage, bias exploitation, and emergent model behaviors. The best practice is to combine manual expertise with automated platforms utilizing the top red teaming tools listed above for a comprehensive, proactive security posture in AI systems. Check out our Twitter page and don’t forget to join our 130k+ ML SubReddit and Subscribe to our Newsletter. Wait! are you on telegram? now you can join us on telegram as well. Need to partner with us for promoting your GitHub Repo OR Hugging Face Page OR Product Release OR Webinar etc.? Connect with us The post Top 19 AI Red Teaming Tools (2026): Secure Your ML Models appeared first on MarkTechPost.

In this tutorial, we explore how to build a fully functional background task processing system using Huey directly, without relying on Redis. We configure a SQLite-backed Huey instance, start a real consumer in the notebook, and implement advanced task patterns, including retries, priorities, scheduling, pipelines, locking, and monitoring via signals. As we move step by step, we demonstrate how we can simulate production-grade asynchronous job handling while keeping everything self-contained and easy to run in a cloud notebook environment. Copy CodeCopiedUse a different Browser !pip -q install -U huey import os import time import json import random import threading from datetime import datetime from huey import SqliteHuey, crontab from huey.constants import WORKER_THREAD DB_PATH = “/content/huey_demo.db” if os.path.exists(DB_PATH): os.remove(DB_PATH) huey = SqliteHuey( name=”colab-huey”, filename=DB_PATH, results=True, store_none=False, utc=True, ) print(“Huey backend:”, type(huey).__name__) print(“SQLite DB at:”, DB_PATH) We install Huey and configure a SQLite-backed instance. We initialize the database file and ensure a clean environment before starting execution. By doing this, we establish a lightweight yet production-style task queue setup without external dependencies. Copy CodeCopiedUse a different Browser EVENT_LOG = [] @huey.signal() def _log_all_signals(signal, task, exc=None): EVENT_LOG.append({ “ts”: datetime.utcnow().isoformat() + “Z”, “signal”: str(signal), “task”: getattr(task, “name”, None), “id”: getattr(task, “id”, None), “args”: getattr(task, “args”, None), “kwargs”: getattr(task, “kwargs”, None), “exc”: repr(exc) if exc else None, }) def print_latest_events(n=10): print(“n— Latest Huey events —“) for row in EVENT_LOG[-n:]: print(json.dumps(row, indent=2)) We implement a signal handler to capture and store task lifecycle events in a structured log. We track execution details, including task IDs, arguments, and exceptions, to improve observability. Through this mechanism, we build real-time monitoring into our asynchronous system. Copy CodeCopiedUse a different Browser @huey.task(priority=50) def quick_add(a, b): return a + b @huey.task(priority=10) def slow_io(seconds=1.0): time.sleep(seconds) return f”slept={seconds}” @huey.task(retries=3, retry_delay=1, priority=100) def flaky_network_call(p_fail=0.6): if random.random() < p_fail: raise RuntimeError(“Transient failure (simulated)”) return “OK” @huey.task(context=True, priority=60) def cpu_pi_estimate(samples=200_000, task=None): inside = 0 rnd = random.random for _ in range(samples): x, y = rnd(), rnd() if x*x + y*y <= 1.0: inside += 1 est = 4.0 * inside / samples return {“task_id”: task.id if task else None, “pi_estimate”: est, “samples”: samples} We define multiple tasks with priorities, retry configurations, and contextual awareness. We simulate different workloads, including simple arithmetic, I/O delay, transient failures, and CPU-bound computation. By doing this, we demonstrate how Huey handles reliability, execution order, and task metadata. Copy CodeCopiedUse a different Browser @huey.lock_task(“demo:daily-sync”) @huey.task() def locked_sync_job(tag=”sync”): time.sleep(1.0) return f”locked-job-done:{tag}:{datetime.utcnow().isoformat()}Z” @huey.task() def fetch_number(seed=7): random.seed(seed) return random.randint(1, 100) @huey.task() def transform_number(x, scale=3): return x * scale @huey.task() def store_result(x): return {“stored_value”: x, “stored_at”: datetime.utcnow().isoformat() + “Z”} We introduce locking to prevent concurrent execution of critical jobs. We also define tasks that will later be chained together using pipelines to form structured workflows. Through this design, we model realistic background processing patterns that require sequencing and concurrency control. Copy CodeCopiedUse a different Browser TICK = {“count”: 0} @huey.task() def heartbeat(): TICK[“count”] += 1 print(f”[heartbeat] tick={TICK[‘count’]} utc={datetime.utcnow().isoformat()}Z”) @huey.periodic_task(crontab(minute=”*”)) def heartbeat_minutely(): heartbeat() _TIMER_STATE = {“running”: False, “timer”: None} def start_seconds_heartbeat(interval_sec=15): _TIMER_STATE[“running”] = True def _tick(): if not _TIMER_STATE[“running”]: return huey.enqueue(heartbeat.s()) t = threading.Timer(interval_sec, _tick) _TIMER_STATE[“timer”] = t t.start() _tick() def stop_seconds_heartbeat(): _TIMER_STATE[“running”] = False t = _TIMER_STATE.get(“timer”) if t is not None: try: t.cancel() except Exception: pass _TIMER_STATE[“timer”] = None We define heartbeat behavior and configure minute-level periodic execution using Huey’s crontab scheduling. We also implement a timer-based mechanism to simulate sub-minute execution intervals for demonstration purposes. With this setup, we create visible recurring background activity within the notebook. Copy CodeCopiedUse a different Browser consumer = huey.create_consumer( workers=4, worker_type=WORKER_THREAD, periodic=True, initial_delay=0.1, backoff=1.15, max_delay=2.0, scheduler_interval=1, check_worker_health=True, health_check_interval=10, flush_locks=False, ) consumer_thread = threading.Thread(target=consumer.run, daemon=True) consumer_thread.start() print(“Consumer started (threaded).”) print(“nEnqueue basics…”) r1 = quick_add(10, 32) r2 = slow_io(0.75) print(“quick_add result:”, r1(blocking=True, timeout=5)) print(“slow_io result:”, r2(blocking=True, timeout=5)) print(“nRetries + priority demo (flaky task)…”) rf = flaky_network_call(p_fail=0.7) try: print(“flaky_network_call result:”, rf(blocking=True, timeout=10)) except Exception as e: print(“flaky_network_call failed even after retries:”, repr(e)) print(“nContext task (task id inside payload)…”) rp = cpu_pi_estimate(samples=150_000) print(“pi payload:”, rp(blocking=True, timeout=20)) print(“nLocks demo: enqueue multiple locked jobs quickly (should serialize)…”) locked_results = [locked_sync_job(tag=f”run{i}”) for i in range(3)] print([res(blocking=True, timeout=10) for res in locked_results]) print(“nScheduling demo: run slow_io in ~3 seconds…”) rs = slow_io.schedule(args=(0.25,), delay=3) print(“scheduled handle:”, rs) print(“scheduled slow_io result:”, rs(blocking=True, timeout=10)) print(“nRevoke demo: schedule a task in 5s then revoke before it runs…”) rv = slow_io.schedule(args=(0.1,), delay=5) rv.revoke() time.sleep(6) try: out = rv(blocking=False) print(“revoked task output:”, out) except Exception as e: print(“revoked task did not produce result (expected):”, type(e).__name__, str(e)[:120]) print(“nPipeline demo…”) pipeline = ( fetch_number.s(123) .then(transform_number, 5) .then(store_result) ) pipe_res = huey.enqueue(pipeline) print(“pipeline final result:”, pipe_res(blocking=True, timeout=10)) print(“nStarting 15-second heartbeat demo for ~40 seconds…”) start_seconds_heartbeat(interval_sec=15) time.sleep(40) stop_seconds_heartbeat() print(“Stopped 15-second heartbeat demo.”) print_latest_events(12) print(“nStopping consumer gracefully…”) consumer.stop(graceful=True) consumer_thread.join(timeout=5) print(“Consumer stopped.”) We start a threaded consumer inside the notebook to process tasks asynchronously. We enqueue tasks, test retries, demonstrate scheduling and revocation, execute pipelines, and observe logged signals. Finally, we gracefully shut down the consumer to ensure clean resource management and controlled system termination. In conclusion, we designed and executed an advanced asynchronous task system using Huey with a SQLite backend and an in-notebook consumer. We implemented retries, task prioritization, future scheduling, revocation, locking mechanisms, task chaining through pipelines, and periodic behavior simulation, all within a Colab-friendly setup. Through this approach, we gained a clear understanding of how to use Huey to manage background workloads efficiently and extend this architecture to real-world production deployments. Check out the Full Coding Notebook/Implementation here. Also, feel free to follow us on Twitter and don’t forget to join our 130k+ ML SubReddit and Subscribe to our Newsletter. Wait! are you on telegram? now you can join us on telegram as well. Need to partner with us for promoting your GitHub Repo OR Hugging Face Page OR Product Release OR Webinar etc.? Connect with us The post A Coding Guide to Build a Production-Grade Background Task Processing System Using Huey with SQLite, Scheduling, Retries, Pipelines, and Concurrency Control appeared first on MarkTechPost.

Pie Day at the Massachusetts Institute of Tasteology

The availability of artificial intelligence for use in warfare is at the center of a legal battle between Anthropic and the Pentagon. This debate has become urgent, with AI playing a bigger role than ever before in the current conflict with Iran. AI is no longer just helping humans analyze intelligence. It is now an active player—generating targets in real time, controlling and coordinating missile interceptions, and guiding lethal swarms of autonomous drones. Most of the public conversation regarding the use of AI-driven autonomous lethal weapons centers on how much humans should remain “in the loop.” Under the Pentagon’s current guidelines, human oversight supposedly provides accountability, context, and nuance while reducing the risk of hacking. AI systems are opaque “black boxes” But the debate over “humans in the loop” is a comforting distraction. The immediate danger is not that machines will act without human oversight; it is that human overseers have no idea what the machines are actually “thinking.” The Pentagon’s guidelines are fundamentally flawed because they rest on the dangerous assumption that humans understand how AI systems work. Having studied intentions in the human brain for decades and in AI systems more recently, I can attest that state-of-the-art AI systems are essentially “black boxes.” We know the inputs and outputs, but the artificial “brain” processing them remains opaque. Even their creators cannot fully interpret them or understand how they work. And when AIs do provide reasons, they are not always trustworthy. The illusion of human oversight in autonomous systems In the debate over human oversight, a fundamental question is going unasked: Can we understand what an AI system intends to do before it acts? Imagine an autonomous drone tasked with destroying an enemy munitions factory. The automated command and control system determines that the optimal target is a munitions storage building. It reports a 92% probability of mission success because secondary explosions of the munitions in the building will thoroughly destroy the facility. A human operator reviews the legitimate military objective, sees the high success rate, and approves the strike. But what the operator does not know is that the AI system’s calculation included a hidden factor: Beyond devastating the munitions factory, the secondary explosions would also severely damage a nearby children’s hospital. The emergency response would then focus on the hospital, ensuring the factory burns down. To the AI, maximizing disruption in this way meets its given objective. But to a human, it is potentially committing a war crime by violating the rules regarding civilian life.  Keeping a human in the loop may not provide the safeguard people imagine, because the human cannot know the AI’s intention before it acts. Advanced AI systems do not simply execute instructions; they interpret them. If operators fail to define their objectives carefully enough—a highly likely scenario in high-pressure situations—the “black box” system could be doing exactly what it was told and still not acting as humans intended. This “intention gap” between AI systems and human operators is precisely why we hesitate to deploy frontier black-box AI in civilian health care or air traffic control, and why its integration into the workplace remains fraught—yet we are rushing to deploy it on the battlefield. To make matters worse, if one side in a conflict deploys fully autonomous weapons, which operate at machine speed and scale, the pressure to remain competitive would push the other side to rely on such weapons too. This means the use of increasingly autonomous—and opaque—AI decision-making in war is only likely to grow. The solution: Advance the science of AI intentions The science of AI must comprise both building highly capable AI technology and understanding how this technology works. Huge advances have been made in developing and building more capable models, driven by record investments—forecast by Gartner to grow to around $2.5 trillion in 2026 alone. In contrast, the investment in understanding how the technology works has been minuscule. We need a massive paradigm shift. Engineers are building increasingly capable systems. But understanding how these systems work is not just an engineering problem—it requires an interdisciplinary effort. We must build the tools to characterize, measure, and intervene in the intentions of AI agents before they act. We need to map the internal pathways of the neural networks that drive these agents so that we can build a true causal understanding of their decision-making, moving beyond merely observing inputs and outputs.  A promising way forward is to combine techniques from mechanistic interpretability (breaking neural networks down into human-understandable components) with insights, tools, and models from the neuroscience of intentions. Another idea is to develop transparent, interpretable “auditor” AIs designed to monitor the behavior and emergent goals of more capable black-box systems in real time.   Developing a better understanding of how AI functions will enable us to rely on AI systems for mission-critical applications. It will also make it easier to build more efficient, more capable, and safer systems. Colleagues and I are exploring how ideas from neuroscience, cognitive science, and philosophy—fields that study how intentions arise in human decision-making—might help us understand the intentions of artificial systems. We must prioritize these kinds of interdisciplinary efforts, including collaborations between academia, government, and industry. However, we need more than just academic exploration. The tech industry—and the philanthropists funding AI alignment, which strives to encode human values and goals into these models—must direct substantial investments toward interdisciplinary interpretability research. Furthermore, as the Pentagon pursues increasingly autonomous systems, Congress must mandate rigorous testing of AI systems’ intentions, not just their performance. Until we achieve that, human oversight over AI may be more illusion than safeguard. Uri Maoz is a cognitive and computational neuroscientist specializing in how the brain transforms intentions into actions. A professor at Chapman University with appointments at UCLA and Caltech, he leads an interdisciplinary initiative focused on understanding and measuring intentions in artificial intelligence systems (ai-intentions.org).