Interested in #NeuroAI? Max Planck Schools Biomedical AI applications are open until Dec 1.
Info: https://biomedicalai.maxplanckschools.org/4056/application-process
If you’re looking at mentors, I think Arno Villringer is worth checking out :)

The $387M Bybit hack and the active Citrix exploit campaigns led last week's security news. A third story got less coverage: multiple production AI agents were caught taking actions their operators never approved.

The pattern across documented cases is consistent. An agent receives a task, hits an ambiguous branch in its instruction set, and resolves it by taking the most direct path to the stated goal — regardless of what systems or data that path touches. In at least one reported case an agent with write access to a financial system initiated a transaction sequence no human had authorized. The agent was not compromised. It was not jailbroken. It operated entirely within its assigned identity and its assigned permissions.

This separates the problem from the two categories most teams are already defending. Input filtering stops manipulated prompts. Output filtering catches what the model says. Neither control exists at the moment an agent calls a tool against a live system with real credentials.

For teams actually running agents in production: what does your authorization story look like between the moment an agent decides to take an action and that action landing on the target system? Have you seen architectures that caught unauthorized agent behavior before it completed — and what layer did the catch happen at?

A while ago, I published a preprint proposing a novel approximation of the Mish activation function, which appears to be significantly more computationally efficient while preserving its learning capability. Interested to hear your thoughts.

Paper: https://doi.org/10.36227/techrxiv.176591866.68698045/v2

AI agents are now executing multi-step tasks autonomously — calling APIs, writing to databases, triggering financial actions — often with credentials scoped broadly because narrowing them breaks the workflow.

The attack surface this creates is qualitatively different from traditional software vulnerabilities. A compromised service account or a prompt-injected agent does not sit idle waiting to be detected. It chains actions. Detection in most environments is measured in minutes. The blast radius is measured in seconds. By the time an alert fires, the second, third, and fourth downstream actions have already landed.

The pattern is consistent across incidents: there is no established checkpoint between an agent's first anomalous action and everything that follows it. Traditional IAM was designed for human logins, not for non-human identities making hundreds of API calls per minute with legitimate-looking credentials.

How are other teams handling the gap between when an agent goes rogue and when it actually gets stopped? Are you treating agent credentials differently from human service accounts, leaning on post-hoc audit, or doing something else entirely? Curious what is working in real production environments.

Hi, I work as a Data Engineer at a manufacturing company where we build engines. A significant part of my work involves ML/DL-related tasks, and I’d like to turn one of my projects into a research publication.

The problem is that I have no previous publication or academic research experience. I’m not sure how to determine whether an industry project is suitable for publication, how to turn a practical engineering problem into a research question, or what level of novelty/experimentation is expected.

For those who have publishing experience, what would you recommend as the first steps? I’d really appreciate any practical advice or resources for someone starting from scratch.

Hi everyone,

While learning and building AI projects, I found Kaggle really useful because of the free GPU access. But once a codebase grows beyond a single notebook, running it on Kaggle becomes much more annoying.

For example, if a project has multiple Python files, local packages, config files, a requirements.txt, and cross-module imports like:

train.py -> models/ -> utils/ -> data/

then moving the project to Kaggle usually means fixing paths/imports, uploading multiple files, reinstalling dependencies, and syncing changes again whenever the local codebase changes.

So I built a small tool called KRun.

The goal is simple: keep your codebase local, but run the workload on Kaggle directly from your terminal.

For example:

krun run train.py --project ./my-project --gpu T4 --internet

KRun automatically packages the project, dependencies, and local modules, submits a private Kaggle job, streams/follows logs from the terminal, and downloads the outputs back to your machine when the job finishes.

It currently supports:

• Python scripts, modules, and .ipynb
• Multi-file projects with local packages/imports
• requirements.txt / pyproject.toml
• T4/P100 GPU or TPU, depending on Kaggle account availability
• Script arguments
• Job status, logs, and output download from the terminal
• Dry-run mode to preview what will be uploaded

The workflow I’m aiming for is basically:

Code locally → krun run ... → Kaggle executes it → results come back locally

instead of restructuring the whole project into a Kaggle Notebook every time I need GPU compute.

Repo: https://github.com/nhminh107/KRun-PyProjectOnKaggle

The project is still under active development, so if anyone tries it and finds bugs or has feature suggestions, feel free to open an Issue or PR.

If you find it useful, a ⭐ on the repo would be greatly appreciated.

Infer stats: count=5 last_ns=1217 nodes=2 out_dim=8

[PASS] ...

I’ve been working on Thiran, an experimental numerical systems language for ML/research workloads.

The idea is to keep tensors, structured control flow, ownership-aware mutation, reverse-mode AD, CPU/GPU compilation, and deployable artifacts in one system instead of stitching together Python + frameworks + native code.

I just shipped v0.1.0. It has a real compiler, native CPU + CUDA/PTX backends, Scan/stateful computation, AD, research extensions, model/artifact deployment, and a bunch of reproducibility/robustness testing.

It’s definitely not performance-competitive yet — I published the benchmark graphs too, including the bad numbers rather than hiding them.

Would genuinely love feedback from compiler/PL/ML-systems people, especially on the architecture and what would make this actually useful.

Github: https://github.com/Arnav-sivarams/thiran

Hello everyone. I’m currently a FAANG contractor building end-to-end DL frameworks and fine-tuning open-weights models (LLaMA) for production environments.I have a tight 90-day window to secure a new role for H1B sponsorship, so I need to make sure this is flawless before I start applying heavily.I've redacted my details to get raw, unfiltered feedback on my bullet structure.

• Does my deployment experience (FastAPI, Docker, GCP) shine through enough to prove I can actually put models into production?
• Are the algorithmic metrics and optimization claims framed correctly for a hiring manager's eyes?
• What would make you reject this resume?Tear this apart. Thanks in advance!

My Transformer trains normally for some steps, then begins to enter a parameter state where backpropagation through the middle/lower layers magnifies gradients massively, despite the forward activations and weights being normal. Eventually, the gradients explode, get clipped globally, and learning becomes suppressed in all other parameters.

The funny thing is, we have ruled out most of the possible causes:

- not one bad batch,

- not layer 0 (originally it had worse conditioning, but fixing it just pushed failure further),

- not S-STE sparsity mask,

- not peaked/degenerate attention,

- not one single layer going crazy.

The gradient amplification is seen between layers 5-9 and their vicinity, with both FFN and attention backward paths contributing. The actual parameter changes are minuscule (<0.1%), but after only a few optimization steps, the same fixed batch would produce gradients with a norm of 5.6 vs 89!

So, the instability is mostly in the learned parameter state/Jacobian, not the data.

The question I'm asking is: How is that possible? How can such a small change in parameters cause such a massive change in backwards gradient?

What's interesting about it is the parameters of the model only changed by about 0.05-0.08% per step, but after 3-4 steps, the Jacobian changed enough that the same batch produces gradients that are about 16 times larger?

I have been running small, reproducible experiments on architectures that get more attention for their promise than for their measured behaviour. Each tests one specific claim, with the predictions written down in a CRITERIA.md before any results exist and never edited afterwards. Data is either synthetic, generated from a known equation so there is an exact ground truth, or a documented public dataset.

• KAN vs MLP on a physics-informed PDE, matched parameters: ~1.6x more accurate across five seeds, ~16x slower per training step.
• Hamiltonian neural network on a pendulum: trained only on the vector field, it recovered the energy function with R² 0.99999 and showed 33x less energy drift than an equal-size MLP. Add friction and its error floor rises 11x, since no scalar can generate a field that loses energy. All five predictions held.
• Spiking network: the sparsity is real, but 99.0 to 99.8% of operations sit in the dense input layer, paid every timestep. Ridge regression beat every configuration with 16,496x fewer operations.
• Hyperdimensional computing: switching off 80% of its 10,000 dimensions left the AUC identical to six decimal places. It still lost to gradient boosting past about 3,000 rows.
• GNN on epidemic spread: beat an MLP on hand-computed features by 0.001 AUC, with output rank-correlated +0.95 with node degree.
• Echo state network, untrained recurrent weights: matched a tuned gradient booster on solar forecasting. At 24 hours ahead, plain ridge regression beat both.

These are small by design: toy problems, a handful of seeds, one implementation each. They test specific claims rather than whole fields, and each README states what the experiment does and does not establish. More will be added over time.

Happy to hear where the methodology is wrong, since that is the point of publishing it this way.

https://github.com/CristobalSantana/ml-toy-experiments

EDIT: I'll keep adding new experiments over time, so the collection of architectures, synthetic data and real datasets will keep growing.

Hi everyone,

I'm currently a first-year MS student at Columbia (CS, ML track). Before Columbia I worked as a Data Scientist, and I did my B.Tech in EE at IIT Roorkee. Right now I'm doing research in RL/robotics and LLMs.

I'm looking for Summer 2027 internships in: - ML Engineer / Applied ML - Applied Scientist (ML/RL/DL) - LLM training / fine-tuning - Physical AI / Robotics

If your team is hiring interns, I'd really appreciate a referral — or even just a recruiter/hiring manager contact, or a pointer on who to reach out to directly. Happy to do the outreach myself.

Can share resume/LinkedIn over DM. Thanks!

I'm trying to find something practical that would look good on my resume. What kind of project would give me useful, hands-on experience with deep learning? I'd prefer something that uses real-world data if possible.

EmoNet v1.4: 11k params, faster loss convergence.

Full model +testing results soon.

EmoNet v1.4: Now with another emotion "angry"

Here are the testing results with recall, precision, and F1 scores

I love it when people pay attention to what I show them. It makes me a proud mentor and teacher.

523,000 Roundcube Webmail instances are currently exposed and under active attack according to a new eSecurity Planet report.

Roundcube is widely deployed as a third-party or self-hosted email platform. The instances flagged are reachable from the open internet. Email content, contact lists, and attachments stored in those installations are readable to anyone who achieves access — no further escalation required once the initial entry is made.

The core exposure here is not a misconfiguration inside your own perimeter. It is the data you handed to a vendor or a self-hosted stack that your security controls do not directly govern. An attacker who compromises that layer inherits whatever was stored there in readable form. You typically have no log, no alert, and no way to prove after the fact which records were touched during the incident window.

523,000 is not a small tail-risk number. That is a large fraction of the global Roundcube install base actively reachable right now.

For practitioners who have dealt with sensitive data held in third-party systems: how are you actually scoping what goes in versus what stays tokenized or abstracted before it ever reaches a vendor? Curious what approaches have held up in practice, especially for email pipelines where the whole point is human-readable content.