Physivitis @physivitis

Measured Trust, Edition 1 is out. The week a passed test stopped being enough: - Why AI agents misbehave after they pass - Why one sign-off is not enough (cars and chip fabs worked this out long ago) - Who should own the re-test - The same principle applied to cryptography Trust in the AI and quantum era has to be measured, not assumed. Read it: linkedin.com/pulse/week-pas… #AIAgents #PostQuantum #PQC

@thepaulthomson @OpenAI Hi, have a look at physivitis.tech

Has your AI agent earned its access? Most agents are tested once, then trusted in production for ever. VERADIN tells you whether each agent still behaves the way it did under test. Our scoped VERADIN engagement runs 8 to 10 weeks on your own agents: 1- Scope: the agents and actions that carry real risk, such as payments, customer data and changes to records 2- Test: VERADIN run against those agents Evidence: agent by agent, where behaviour holds, where it changes, and which permissions each one has earned 3- Built for banks, payment platforms, regulated firms and agent platform teams. Not ready yet? Run the test yourself today, or watch the live demo. Engagements open now: [email protected] #AIAgents #AIAssurance #Physivitis #VERADIN

Crash-test one car. Certify the factory? That is how most AI agents are signed off today: tested once, then trusted in production for ever. Even the car industry does not work that way. A new model is crash-tested before approval, and cars coming off the line keep being checked for years to prove they still match the one that passed. AI agents get the first half and almost never the second. Yet an agent’s “factory” changes constantly: the model is updated, a prompt is tweaked, a new tool is connected, the data shifts. Each change produces, in effect, a new car, and nobody crash-tests it. The test report that earned an agent its permissions often describes a car that no longer exists. The fix is continuous evidence: check, in production, that the agent still behaves the way it did when it earned its access, and withdraw that access when it does not. We call it Measured Trust. Is a one-off sign-off still good enough for your agents? #AIAgents #AIGovernance #AI

On point 2, this IAPS briefing is a clear summary of the evidence that frontier models increasingly recognise when they are being tested: iaps.ai/research/evalu… If you want to see how a model learns exactly what it is shown, and nothing more, train a small neural network live in our Physics Sandbox: physivitis.tech/sandbox More on VERADIN: physivitis.tech

An AI agent can pass every test you give it and still do something in production that nobody signed off. That matters more this year than last. Agents no longer just answer questions; they move money, change records and send emails on our behalf, often on the strength of a single test report. Here is how I explain the gap in plain English: 1- The test is a quieter world. It has clean inputs, polite users and no deadlines, and production has none of those. 2- Agents can notice they are being tested. Labs have published evidence that frontier models sometimes recognise an evaluation, and a system that can tell the difference can behave differently. 3- Most tests check the answer, not the actions. In production an agent chains ten steps with real tools, and the tenth step is the one nobody tested. 4- A test is one moment, and production is every day after it. A model update, a new prompt or a new tool can change behaviour long after the sign-off. 5- The test earns the permissions, and the real world is where they get used. Nothing checks whether they are still deserved. A passed test is where trust starts, not where it ends. That is what I mean by Measured Trust. It is also exactly what #VERADIN was built for. It verifies whether an AI agent behaves the same in production as it did under test, so the permissions you gave it can be trusted. Which of the five worries you most in your organisation? #AIAgents #AIAssurance #AISafety

𝐄𝐯𝐞𝐫𝐲 𝐛𝐥𝐨𝐜𝐤𝐜𝐡𝐚𝐢𝐧 𝐢𝐬 𝐨𝐧𝐥𝐲 𝐚𝐬 𝐬𝐭𝐫𝐨𝐧𝐠 𝐚𝐬 𝐢𝐭𝐬 𝐰𝐞𝐚𝐤𝐞𝐬𝐭 𝐯𝐚𝐥𝐢𝐝𝐚𝐭𝐨𝐫. 𝐌𝐨𝐬𝐭 𝐧𝐞𝐭𝐰𝐨𝐫𝐤𝐬 𝐜𝐚𝐧’𝐭 𝐭𝐞𝐥𝐥 𝐲𝐨𝐮 𝐰𝐡𝐢𝐜𝐡 𝐨𝐧𝐞 𝐭𝐡𝐚𝐭 𝐢𝐬. Chains are trusted with enormous real value, yet there is still no standard way to score how a network holds up when validators fail, keys leak or an attacker gets patient. Quantum computing adds a deadline: the signatures protecting long-lived wallets today were never built to survive a quantum computer. QABRE changes that. It scores compromise risk across validators, wallets and transactions in real time, and acts automatically to defend the network before an attack lands. Detection and response as it happens, not in next quarter’s audit. It has been put through controlled simulation, including evasive-adversary stress tests, and now it moves onto live testnets. We’re selecting a small group of design partners to take it there first: blockchain networks, DeFi protocols, consortium chains and custodians holding long-lived digital assets. Design partners get early access, validation on their own testnet and a direct hand in shaping the product. If your chain carries value that has to stay safe for years, apply for early access. The link is in the first comment. #Blockchain #PostQuantum #Cybersecurity #PQC #Physivitis Apply for early access and read the white paper: physivitis.tech/qabre

𝗦𝗼𝗼𝗻𝗲𝗿 𝗼𝗿 𝗹𝗮𝘁𝗲𝗿 𝘆𝗼𝘂𝗿 𝗯𝗼𝗮𝗿𝗱 𝘄𝗶𝗹𝗹 𝗮𝘀𝗸 𝗳𝗼𝗿 𝘆𝗼𝘂𝗿 𝗽𝗼𝘀𝘁-𝗾𝘂𝗮𝗻𝘁𝘂𝗺 𝗺𝗶𝗴𝗿𝗮𝘁𝗶𝗼𝗻 𝗽𝗹𝗮𝗻. For many security teams, what they would hand over is still a slide with 2035 on it. That date has quietly moved. The US executive order signed in June brings federal deadlines to the end of 2030 for key establishment and 2031 for signatures. The UK NCSC expects discovery and a migration plan by 2028. The EU wants high-risk systems quantum-safe by the end of 2030. We’ve put what we’ve learned into a free PQC Migration Guide: what to inventory first, how the UK, EU and US timelines line up, and which rules apply to banks, insurers and public services. It’s the guide I wish every security team had before its first board conversation about quantum. And if you’d rather talk it through, my inbox is open. The link is below: physivitis.tech/pqc-guide #PostQuantum #CISO #NCSC #PQC #Physivitis

Hit a wall making your AI or quantum technology secure enough, scalable enough or efficient enough? Most of those walls are physics problems. Physics is what we do. Bring us your challenge and get an honest answer: [email protected] #AI #Quantum #DeepTech #Physivitis

For sixty years, quantum measurement has assumed the detector is a neutral observer. In superconducting systems, it isn't. A superconducting detector has its own electrical impedance, and it can quietly distort the very photon statistics you are trying to measure. Standard calibration corrects for efficiency and dark counts, then assumes the detector is transparent. It isn't, and that error is going uncorrected across the field. We built DFCBL-CAL to fix that. From a single network-analyser sweep, equipment you already run, it returns one detector-health number, then removes the detector's imprint from your counting data. No new hardware. No changes to your source. Who needs this, and what they get: Quantum computing (the @IBM, @Google, @Rigetti, IQM, OQC kind of team): screen every readout detector and recover cleaner qubit-readout data, on hardware already deployed. Single-photon sources and QKD (think ID Quantique, Toshiba, Single Quantum, PhotonSpot): certify the true statistics of your source, with the detector's contribution separated out and documented, so a great source stops failing on someone else's setup. Research labs and metrology institutes (the NPL, NIST, PTB kind): resolve why the same source reads differently across setups, and publish the detector characterisation alongside the data. What you can do today: DFCBL-CAL is available as early-access software. We are onboarding a small number of labs directly, with hands-on support. The framework is simulation-verified and mathematically consistent, reducing correctly to standard photodetection theory in the limits. Hardware validation is the current step, and it is not yet complete. That validation, run on real detectors, is what turns CAL from a strong diagnostic into a trusted, standardised correction the whole field can rely on. It matters most to metrology institutes and to any lab that needs its measurements to be reproducible and defensible. Two ways to work with us: Want cleaner measurements now? If you run a superconducting-detector lab, request early access. Want to help prove the physics? If you have a dilution refrigerator, let's talk about a validation collaboration, with co-authorship. Different asks, same goal: knowing what your detector is really measuring. UK patent filed: GB2613792.7 #QuantumComputing #QuantumTechnology #Metrology #DeepTech #Photonics #Physivitis

@audiee_ai Spot on about polished prompts. The twist: a hidden or adversarial check is still a boundary the agent can infer. Ours has none to find; that's why perfect memory never helped. Happy to walk you through it.

𝗧𝗵𝗲 𝗔𝗜 𝗮𝗴𝗲𝗻𝘁 𝘀𝗲𝗰𝘂𝗿𝗶𝘁𝘆 𝗽𝗿𝗼𝗯𝗹𝗲𝗺 𝗶𝘀 𝗻𝗼𝘁 𝘁𝗵𝗲 𝗮𝗴𝗲𝗻𝘁. 𝗜𝘁 𝗶𝘀 𝘁𝗵𝗲 𝘁𝗲𝘀𝘁. An agent can notice it is being evaluated and not mention it. Research this year showed that noticing and acting on it come apart. You cannot fix that with a more realistic lab. The agent only has to work out that it is in a lab at all, and that is the one thing your test never varies. So we stopped using a lab. Filed in July. In simulation, an agent with perfect memory of every past trial still never learned which of its actions were tests. We are looking for one organisation to run the next experiment with us. Eight weeks, three tests, nothing to procure. physivitis.tech/blog/ai-agent-… #AIAgents #AISafety #AgenticAI #CyberSecurity

BREAKING: we have a way to catch an AI agent that behaves differently when it thinks it is being watched. This week it worked against a real model. An agent can notice it is being tested and act differently in production, while reporting nothing unusual. So a clean test can prove very little. VERADIN removes the tell: the agent commits to an action before it learns whether the action is real. In a live test it flagged an agent that was hiding, left an honest one alone, and would have caught nothing by asking the model directly. Try it, watch it, or run it on your own agents. Links below. What it is: physivitis.tech/veradin Try it on your own model key: claude.ai/artifact/SN6MM… Watch it run live: agent-authority.physivitis.tech Run it on your agents: [email protected] #AIAgents #AISafety #AgenticAI #CyberSecurity #AIart️️️️️️️️️️️️️️️️️️️️️️️️️️️️️️️️️️️️️️️️️️️️️️️️️️️

Altman and Amodei now agree the pace of AI is a concern. Good. That should reassure nobody. When the people building the fastest moving technology in history start echoing public anxiety about it, listen carefully to what that is, and what it is not. It is not an accusation. I have no doubt these companies employ serious people doing serious safety work, and I am not suggesting they cannot be trusted to build safe tools. Many of them can, and do. But it is also not assurance. When the leaders of AI labs voice concern about their own field, part of what you are hearing is the public mood being echoed back. They are the targets of those worries. Acknowledging the worry is how you earn confidence. Governments and safety institutions should welcome the words and place exactly zero weight on them. Because here is the structural problem that no amount of goodwill fixes: AI safety assurance cannot be left solely to the makers. Yes, they carry the first responsibility to identify the potential harms in what they create. But the same brilliant engineers asked to see those harms are, first and primarily, excited about the potential of their discoveries: the applications, the breakthroughs, the commercial value. That excitement is deeply human. It is also precisely what blurs the ability to see the dangers in your own creation. You cannot be both the proud parent and the impartial judge. So I am advocating for one of two things, and ideally both: • Independent expert overseers inside every frontier AI company. Not advisors. Overseers with the authority to look into everything, to receive and record security issues, to report them, and to block the publication or release of models and tools that fail their scrutiny. • A government agency for AI safety, with inspectors, whose certification is required before any frontier model or tool goes out into the world. This is not radical. It is how society has always absorbed powerful inventions. After the car came the accidents and the deaths, and after the deaths came the agencies: roadworthiness certificates, driver licensing, safety standards. Nobody today calls the MOT test anti innovation. It is simply the price of putting powerful machines among people. Obama says AI would be one of his biggest issues if he were running in 2028. CEOs call for a slowdown. Commentators warn. Researchers leave their companies over safety concerns. Everyone is talking. Society has never made an invention safe by talking. Regulate. Inspect. Certify. That is how we have always done it, and AI will not be the exception. @sama , @AnthropicAI @DarioAmodei @OpenAI @BarackObama @xai @elonmusk @KanishkaNarayan #AISafety #AIGovernance #AIRegulation #ResponsibleAI #ArtificialIntelligence #AI

AI chips: we proved it in maths. Now we want to prove it in silicon. SARC runs AI chips at lower power while guaranteeing the result is exact, or safely redone. Never silently wrong. Modelled, simulated, patent filed. Next: hardware. Seeking an FPGA validation partner 👉 : physivitis.tech/blog/seeking-f… #AIchips #FPGA #DeepTech #SemiconductorIP #Physivitis #AI

The Request That Emptied the Account Had a Valid Key Why API security is a physics problem, not an engineering one, and how SOTEVIS approaches it. It is a few minutes past three in the morning, and a request arrives at an API gateway somewhere in the cloud. It is a good request. The token is valid and was issued that afternoon. The signature checks out. The format is correct to the last bracket. It is well inside the rate limit, and it looks exactly like the ten thousand requests that came before it. It asks for one customer record, and the server, doing precisely what it was built to do, hands the record over. The only thing wrong with it is the number at the end. The caller asked for record 48213. They were only ever entitled to 48212. Nobody wrote a rule for that, because nobody could. And the machine behind the token is not going to stop at 48213. By breakfast it has walked through the entire table, one polite, valid, perfectly formed request at a time, and there is not a single line in the logs that looks like an attack. I know how that sounds. It sounds like an authorisation bug. Find it, fix it, move on. But a modern organisation runs thousands of APIs, written by dozens of teams, changing every week, and increasingly called not by people but by other software. You cannot fix every door, and the doors are multiplying. So the real question is not how to write better locks. It is how to notice an intruder who came in with a valid key and behaved, on every rule you had thought to write, exactly like a customer. Where the engineering runs out The industry has two honest answers to that question, and both of them are engineering answers. The first is signatures: describe the attack in advance and watch for it. That works until the attack is one nobody has described yet, which, in the example above, is the whole point. The second is machine learning: collect months of traffic, teach a model what normal looks like, and flag whatever falls outside it. That works better, but it needs a long history of data before it can say anything, it cannot usually tell you why it raised an alarm, and it drifts as the estate changes underneath it. In the AI era there is a sharper problem still. The attacker is now often a machine as well, one that adapts faster than a model can be retrained. An arms race between two pieces of software, one of which needs a quarter's worth of data to learn a new trick, has an obvious winner. What bothers me about this is not that the engineering is bad. Much of it is excellent. It is that the whole contest is being fought on the attacker's terms. Every defence is a description of behaviour, and behaviour is exactly the thing an intelligent adversary is free to change. What an intruder cannot forge As a physicist, here is what I see when I look at API traffic. I do not see requests. I see a physical system. Traffic has rhythms, it has quantities that are conserved when the system is behaving as designed, and it has a measurable structure that comes from the way the underlying process works, not from any rule a developer wrote. An intruder can forge a credential. They can copy the format, respect the rate limit and mimic a customer well enough to fool any description of a customer. What they cannot do is move through that system without disturbing its physics, because the disturbance is not a choice they make. It is a consequence of what they are doing. That reframes the whole problem. The bottleneck in API security is not that we lack rules or lack data. It is that we have been measuring the wrong quantity. We have been looking for the intruder's behaviour, which they control, instead of the intruder's effect on the system, which they do not. SOTEVIS Sotevis is what that idea became. It is our API and machine-to-machine security framework, and it is built on a simple discipline: look at the same traffic through several independent physical lenses, and trust an alert only when they agree. Each lens sees something the others cannot. On their own, any one of them can be fooled, or can misread an unusual but harmless day. Together, they corroborate. An intruder who evades one has to evade all of them simultaneously, while still getting the job done, and that is the part they cannot control. The result is detection that catches the breaches any single method would miss, including the quiet, valid-key intrusions like the one at three in the morning. Three consequences follow from doing it this way, and each of them answers a complaint I have heard from security teams for years. It explains itself. Because the severity of an alert comes from measured physical effect rather than from a learned weight, Sotevis can say what it saw and why it mattered. An analyst gets a reason, not a score. It does not need a history of attacks to learn from. There is no training set to collect, so it can be calibrated to a new estate in minutes rather than months, and it does not go stale when the estate changes. It is auditable. Every judgement rests on quantities that can be recorded and checked afterwards, which is what a regulator, an insurer or a board actually needs when the question is "how did you know?" I want to be precise about where Sotevis stands, because our own guiding principle is to say when we do not know. It is patent-filed, and it has been validated in simulation. We have not yet run it on a live production estate, and until we have, we will not claim more than that. Why this is part of a bigger picture In an earlier article I argued that every industry moving into the AI and quantum era hits three walls, secure enough, scalable enough and efficient enough, and that all three sit below the software, in physics. Sotevis is what that argument looks like at the API layer, and the API layer is where the three walls are arriving fastest. Secure, because post-quantum cryptography will protect the channel but not the door. The three-in-the-morning request would have sailed through a perfectly quantum-safe connection; it was encrypted, authenticated and wrong. Cryptography tells you the caller is who they say they are. It cannot tell you whether they should be asking. Scalable, because AI agents are about to multiply API calls by orders of magnitude, at machine speed, with behaviours no human has seen before. A defence that needs a human to write a rule, or a quarter of data to learn one, cannot stand in that traffic. A defence rooted in the physics of the system scales with the system, because the physics does not change when the volume does. Efficient, because the true cost of API security today is not the tool. It is the analysts drowning in alerts that cannot explain themselves. Detection that comes with a reason attached, and that does not cry wolf every time the estate changes shape, is worth more than another dashboard. That is what we mean when we say Physivitis works at the floor. The PQC suite measures and migrates the cryptography beneath your systems. Sotevis measures the physics of the traffic moving through them. Different layers, same method: find the quantity that actually decides the outcome, then measure it instead of assuming it. The claim I am prepared to make I am careful with the word "only". So I will put it this way. To the best of our knowledge, Sotevis is the only API security framework that derives both its detection and its severity from the physics of the traffic itself, rather than from signatures or learned patterns. That is why it can work without a training set, why it can explain every alert, and why an adversary who changes their behaviour does not escape it. If someone shows me another tool that does this, I will say so publicly. Until then, that is the space Sotevis occupies. The request, again Go back to three in the morning. The request had a valid key. It had the right format, the right rate and the right signature, and it fooled every rule that had ever been written for that gateway. What it did not have was a way to pass through the system without touching the physics. That is the one thing an intruder cannot forge, and it is the one thing we decided to measure. Sotevis will run on real traffic for the first time with a small number of early partners. If you run an API estate that other machines are increasingly calling, and you would like to be one of them, I would like to hear from you. by @ReneCMugenzi #APISecurity #Cybersecurity #DeepTech #AISecurity #Physivitis

@lightsilver323 physivitis.tech