Artificial intelligence systems are becoming more capable and autonomous, raising new questions about how they can be monitored, controlled and secured. Speaking before the United Nations Security Council, OpenAI CEO Sam Altman warned that the rapid pace of AI development could create significant AI security risks, particularly if systems advance faster than institutions can respond. Altman highlighted concerns ranging from human control and autonomous AI to emerging vulnerabilities, concentrated technological power and the need for international incident reporting. He also called for stronger cooperation between governments, critical infrastructure operators and technical experts to address emerging AI threats.

Here are six key AI security risks highlighted in his remarks.

1. Losing Human Control Over Advanced AI

One of Altman’s central concerns was the possibility that humans could lose control over increasingly capable AI systems. He warned that AI could move so quickly that people may no longer be able to understand what systems are doing or intervene when necessary. He argued that developers should not train systems unless they can make a strong case that those systems can remain under human control. The concern becomes more significant as AI systems become capable of handling increasingly complex tasks and making decisions with less direct human involvement.

2. AI Systems Becoming More Autonomous

The growing autonomy of AI systems presents another challenge for AI cybersecurity. Altman pointed to the possibility of AI systems improving themselves and future versions of themselves, describing this as recursive self-improvement. As the process of developing AI becomes more automated, the pace of progress could accelerate. For security teams and policymakers, increasingly autonomous systems could make monitoring, testing and intervention more difficult.

3. Emerging Vulnerabilities and New Threats

More capable AI systems could also introduce vulnerabilities and threats that organizations and governments may not yet fully understand. Altman called for secure channels between governments, critical infrastructure operators and technical experts to share information about emerging vulnerabilities and threats. The remarks place information sharing at the center of preparing for AI vulnerabilities, particularly as AI becomes increasingly integrated into important systems and infrastructure.

4. AI Power Concentrating in Too Few Hands

Altman also warned about the concentration of advanced AI capabilities among a small number of companies, individuals or countries. He argued that no single company or country should be able to use the most powerful AI systems to impose its worldview on others. From a security perspective, concentrated control over highly capable AI could create systemic risks if a limited number of actors have disproportionate access to powerful technology.

5. The Need for Global AI Incident Reporting and Threat Sharing

Altman called for accurate and speedy AI incident reporting, including classification and reporting protocols that would allow countries to learn from failures before they become larger problems. He also called for common standards covering AI capabilities, risk assessments, safeguards and human oversight. Such standards, he said, could help countries compare evidence and establish a shared understanding of what effective safeguards and oversight should look like.

6. AI Development Could Outpace Existing Safety Measures

The speed of AI development itself could become a security challenge. Altman warned that rapid progress could move faster than institutions are prepared to handle. He argued that competition between companies should not become a reason to accept excessive technological risk. He also stressed the importance of alignment, monitoring and safety guarantees as AI systems become more capable. For AI safety, this means ensuring that security measures and oversight develop alongside increasingly powerful systems rather than being added only after problems emerge.

AI Security Moves Into a Global Conversation

Altman’s remarks put AI security risks alongside broader questions about international cooperation, human oversight and technological governance. His proposed approach includes global standards for measuring AI capabilities and risks, incident reporting mechanisms, and secure communication between governments, critical infrastructure operators and technical experts. As AI systems become more autonomous and capable, the challenge will not only be what these systems can do, but whether organizations and governments can monitor, understand and respond to the risks they create.

AI is changing how software is built, tested, and secured, but the speed of development is also creating new challenges for application security teams. As AI coding tools and autonomous agents increase the volume and pace of software development, security teams are facing a growing gap between vulnerability detection, prioritisation, and remediation. In this interview with Rahul Sood, GM, Application Security at Harness, we explore how AI application security is evolving as developers increasingly rely on AI-assisted coding and software agents. Sood discusses why traditional checkpoint-based security processes are struggling to keep pace, how organisations can bring security controls closer to the point where code is created, and why automated vulnerability remediation could become increasingly important. The conversation also examines the security risks associated with AI agents that can access repositories, APIs, infrastructure and production environments. Sood explains why identity, least-privilege access, observability and human oversight will become increasingly important as software gains greater autonomy, and why application security will need to address not only what software contains, but also what autonomous systems are authorised to do. Read the full interview below for Rahul Sood’s perspective on the changing application security landscape and the security challenges emerging as AI takes a more active role in software development.

The Cyber Express: What is the biggest change AI is bringing to the application security landscape?

Rahul Sood: The biggest change is speed. We have spent years making software development faster, and AI has accelerated that dramatically. Security processes, however, haven't accelerated at the same rate. Most security scanning is still triggered at fixed checkpoints - a pull request, merge, or nightly build - designed for a world where a developer produces a handful of meaningful commits a day. LLM-based scanning can potentially find 10x more vulnerabilities vs. traditional scanning tools. That sounds great, but it also means the discovery side of the pipeline is now outpacing triage and remediation even more than it already was. That's where AI agents also become part of the answer, not just part of the problem. An agent can identify something and begin acting on it in close to the same motion, which is exactly the kind of compression this gap needs. The challenge is making sure that speed is matched with the right judgment and oversight.

The Cyber Express: AI coding assistants can introduce insecure code at scale. What should teams be doing differently?

Rahul Sood: The instinct is to assume AI-generated code is introducing more vulnerabilities because AI is somehow worse at writing secure code. I don't think that's the real story. Even if AI wrote code exactly as securely as a person does, the sheer volume of code now being produced would still overwhelm the way most organisations scan for issues today. Scanning at the commit is already struggling to keep pace, as we discussed. The next step is pushing security further left than that, into the coding tool or agent itself, so secrets detection, dependency checks, and application security testing happen as the code is being written, and those same controls continue through build and deployment rather than starting over at each stage. You need both: controls at the point of creation to cut volume, and a verification layer that confirms what's really going out the door. I expect the industry to move from automated detection towards much more automated resolution. Systems will increasingly identify an issue, establish whether it is actually exploitable, create a potential fix, verify that fix and then bring a developer in where judgement or approval is required. Human oversight remains important, but it should be concentrated on decisions where human judgement adds value rather than every mechanical step surrounding them.

The Cyber Express: What new security challenges emerge when AI agents can make decisions and take actions?

Rahul Sood: A coding assistant can suggest something insecure, but there are usually other controls between that suggestion and production. An agent with access to APIs, repositories or infrastructure is different. It has been given authority to act. That makes identity, permissions and the scope of that authority fundamental security questions. One principle I think will become increasingly important is that autonomy should be proportional to the consequence of the action. The more consequential and difficult an action is to reverse, the stronger the controls around it should be. More broadly, enterprises will need a security architecture for non-human actors: distinct identities, least-privilege access, short-lived credentials, complete auditability and clear boundaries around which decisions an agent can make independently. The important question isn't how autonomous an agent is. It's what we've given it the authority to do, where the boundaries are, and what happens when it gets a decision wrong.

The Cyber Express: What becomes harder to secure when applications behave dynamically?

Rahul Sood: AI-native applications introduce another layer because some risks only become visible through behaviour. The security question is no longer limited to whether the underlying code contains a known vulnerability. You also need to understand what the system is doing at runtime. One of the more concerning findings in the AI-native application security research we conducted last year was how basic the visibility problem still was. Many security practitioners told us they didn't have a reliable way of identifying all of the LLMs operating within their environment. That's a significant problem because you cannot meaningfully govern something you don't know exists. As applications become more dynamic, understanding behaviour becomes just as important as understanding what's in the code.

The Cyber Express: Is shift-left still enough?

Rahul Sood: Shift-left was an important correction because security was happening far too late. But moving security earlier in development doesn't solve the entire problem on its own, since risk doesn't only enter through code. It can come through a dependency, an API, a model interaction, a deployment configuration, or the way an application behaves once it's actually running. There is also a growing mismatch between how quickly vulnerabilities can be exploited and how long organisations take to remediate them. The 2026 Edgescan Vulnerability Statistics Report puts the average time to close high and critical vulnerabilities at roughly 55 days. At the other end of that equation, exploitation of newly disclosed vulnerabilities can now begin within hours. Finding a vulnerability earlier is useful, but the more consequential metric is the period between discovery and protection. The next phase of application security is less about moving a scanner to an earlier point in the lifecycle and more about compressing the entire exposure window, from discovery to protection.

The Cyber Express: How can teams identify which risks actually matter?

Rahul Sood: Security teams don't have an alert problem as much as they have a context problem. A vulnerability can have a severe technical rating and still present relatively little immediate risk if the affected component isn't reachable or exposed. Another vulnerability with a lower score could sit in an internet-facing, business-critical application and deserve immediate attention. So prioritisation has to move beyond severity. That means combining technical severity with signals like EPSS scores for real-world exploit probability, static reachability analysis to confirm whether a vulnerable path can actually be called, and false-positive reduction to cut out findings that never posed real risk in the first place. The goal shouldn't be to help a security team process 10,000 alerts faster. It should be to make sure they don't have to treat 10,000 alerts as equally important in the first place.

The Cyber Express: What does a healthy developer–security relationship look like?

Rahul Sood: The healthiest organisations I've seen don't treat security as a handoff between two teams. Developers understand that security is part of building good software, while security teams take responsibility for making the secure path practical. If following security policy means leaving the developer workflow, opening a ticket, waiting several days and then interpreting a scanner report, people will inevitably look for ways around the process. That's an operating-model problem, not simply a developer behaviour problem. We saw how wide that gap had become in research we conducted last year. Seventy-four percent of security professionals surveyed said developers viewed security as a blocker to AI innovation. Security teams should define acceptable risk, policies and guardrails. Engineering teams should then be able to work within those boundaries without constantly asking for permission. That is ultimately what a mature DevSecOps model should achieve. Security becomes part of the engineering system rather than another team standing beside it.

The Cyber Express: What one assumption should organisations rethink today?

Rahul Sood: One assumption I would rethink is that knowing what software contains is enough to understand its security posture. Application security has traditionally been very good at analysing components: the code, libraries, dependencies, APIs and vulnerabilities that make up an application. But with autonomous software, knowing what it's made of is only part of the picture. We also need to understand the authority we've given it. An agent may be built from approved components and have no obvious vulnerability in its code, yet still create significant risk because it can access the wrong data, has excessive permissions or can take an action that was never anticipated when those permissions were granted. We have spent decades building security around software that executes instructions written by people. We are now introducing software that can interpret a goal, decide how to pursue it and interact with other systems along the way. The security architecture for that world cannot rely only on finding vulnerabilities. It also has to govern delegated authority. I think that will become one of the defining application security problems of the agentic era.

Want to Be Part of Security Pill?

Are you a cybersecurity professional, researcher, CISO or industry expert with insights to share? The Cyber Express is always looking to bring new voices and perspectives to the cybersecurity community.

If you would like to be featured on Security Pill or discuss a potential podcast collaboration, reach out to us at [samiksha.jain@thecyberexpress.com].

Have a story, expertise, or perspective to share? Let’s start the conversation.

Some of the world's leading democracies are pushing governments and companies to start preparing for post-quantum cryptography before quantum computers become powerful enough to break the encryption systems that protect global digital infrastructure today.

In a joint advisory released Thursday, the G7 Cybersecurity Working Group and the U.S. Cybersecurity and Infrastructure Security Agency (CISA) said organizations should begin their transition to post-quantum cryptography now, rather than waiting until cryptographically relevant quantum computers (CRQCs) are available to threat actors.

Why the Post-Quantum Cryptography Shift Cannot Wait

The publication, titled "Preparing for the Post-Quantum Era: A Call to Action," warns that the quantum computing threat is no longer a distant concern. While the exact timeline for CRQC development remains uncertain, the working group said recent technological advances suggest such machines could emerge sooner than expected, putting widely used public-key cryptography mechanisms at risk.

One of the most immediate dangers is a tactic known as "harvest now, decrypt later," where malicious actors intercept and store encrypted data today with the intention of decrypting it once a CRQC becomes available. This poses a serious risk to governmental records, sensitive personal data, and trade or business secrets that require long-term confidentiality.

The advisory also cautions that CRQCs could eventually be used to target authentication mechanisms, allowing bad actors to impersonate trusted entities, forge data, or compromise equipment. Because supply chain vulnerabilities can cascade, a single organization's delay in adopting post-quantum cryptography could expose entire sectors to compromise.

According to the report, organizations that fail to act may also face business consequences beyond security risk, including exclusion from public procurement contracts and loss of competitive advantage.

Five Priorities for the PQC Transition

The G7 Cybersecurity Working Group outlined five priority areas to guide the global shift toward post-quantum cryptography:

1. Raising awareness — Many organizations still view the quantum threat as a distant or purely technical issue. The group called for awareness campaigns, technical guidance, and workforce upskilling to reframe it as an economic and business risk.
2. Developing national strategies — Countries are encouraged to build strategies that ensure an adequate supply of quantum-safe hardware and software while encouraging adoption, integrating the effort into broader digital privacy and security policies.
3. Advancing research and development — Governments should fund research programs and support pilot projects and testbeds to help organizations test and refine their transition to post-quantum cryptography.
4. Building public-private partnerships — Collaboration between government, industry, and academia is seen as key to developing domestic expertise, lowering transition costs, and sharing playbooks and case studies across sectors.
5. Integrating PQC into cybersecurity requirements — The group recommends treating post-quantum cryptography adoption as a natural evolution of cryptographic best practice, and embedding requirements into public procurement to push both vendors and organizations toward quantum-safe systems.

The advisory emphasizes that the shift to post-quantum cryptography cannot be solved by individual organizations in isolation. Instead, it calls for early engagement, coordinated planning, and informed decision-making across public and private sectors worldwide.

Tackling the risks that the impending quantum computing era poses to current cryptographic systems... requires a coordinated global effort to transition to PQC," the report states, adding that public and private organizations must act now to safeguard confidential data, supply chains, and critical systems.

The document was jointly published by cybersecurity authorities from Canada, Germany, Italy, Japan, the United Kingdom, the United States, and France's ANSSI, with participation from the European Commission and support from the EU Agency for Cybersecurity (ENISA).

We talked about the latest release of Delphi a few days ago, and that brought me to Hans Otten’s website.

This site is about my experience with the Wirth school of languages, based on the ideas and implementations of Prof Niklaus Wirth, Kenneth Bowles, Per Brinch Hansen, colleagues, and their students. And my experience with the various variants, from the P2 and P4 compilers originating in Zürich ETH, via UCSD Pascal P-System to the Borland compilers and Modula and Oberon systems. All applicable to small computers and device control.

On this website you will find information on Pascal for small machines, like Wirth compilers, the UCSD Pascal system, many scanned books and other files on UCSD Pascal, Pascal on MSX and CP/M, Delphi programming on PC, Freepascal and Lazarus on Windows and Raspberry Pi, Oberon systems. Many sources of early Pascal compilers! And last but not least my Pascal-M system!

↫ Hans Otten

If you’re into Pascal and its related languages and technologies, this is a treasure trove of information.

Delphi is still very much a thing, and still very much in active development. The current stewards of Delphi, Embarcadero, released the Delphi 13 Community Edition today.

Delphi Community Edition is a full-featured, free edition of Delphi for building native applications with the Delphi language. It includes a professional IDE, visual designers, integrated compilers and debuggers, the VCL framework for Windows development, and the FireMonkey framework for creating native applications from a shared codebase across Windows, macOS, iOS, and Android.

It is designed for students, hobbyists, freelancers, and small teams that meet the Community Edition license requirements.

↫ Marco Cantu at the Embarcadero blog

Delphi has been around since 1995, first released for Windows 3.1. It’s both a programming language, a variant of Object Pascal, and the accompanying IDE and related tooling and frameworks, originally developed by legendary company Borland. This latest version of course adds a number of new features to the programming language, and further improves the IDE as well, this time with a brand new 64bit version. The two frameworks for visual application development, VCL and FireMonkey, have also been updated and improved.

Sadly, it’s not open source, and the Community Edition is intended for mostly non-commercial, hobbyist use. If you want to actually earn any money using Delphi, you’re going to have to step up to Delphi 13 Florence, which isn’t free.

I found some ambiguous wording in the c89(/c90) standard, where GCC and Clang disagree on the interpretation. It concerns the behavior of implicit function declarations, which were removed in c99, so this was never disambiguated.

↫ Sebastian at sebsite

I am not going pretend to understand any of this.

I have a policy to effectively never link to YouTube videos. I’ll gladly make an exception for this one.

Reflection is one of the most powerful concepts in Computer Science. Unfortunately, not every programming language is blessed enough to have it.

In the 1980s, one company, Symbolics took the concept to the logical extreme. By representing EVERYTHING as objects; they created the most powerful (and inadvertently) least private operating system ever created!

The company collapsed, but the ideas live on. Some modern languages got a full dose of reflection. Some…weren’t so lucky. I ranked them all, and in the end I’ll show you how I dragged C++ up a tier with my brand new runtime reflection library, CallMeMaybe!

↫ Laurie Wired

The GitHub description of CallMeMaybe:

CallMeMaybe (CMM) is a C++ runtime reflection library built on top of P2996 static reflection introduced in C++26. CMM purposefully mirrors many of the std::meta functions to provide a uniform interface, but allows runtime introspection, dynamic invocation, and instantiation by building a runtime reflection registry. Class members can be automatically traversed and reflected by simply adding [[=cmm::reflectable]] as an annotation. CMM implements a custom type system to completely avoid RTTI requirements.

↫ CallMeMaybe GitHub page

My YouTube linking policy will remain in place.

Tcl, or the “Tool Command Language“, created and released by John Ousterhout in 1990, deserves a place among the greatest products of the human mind. Especially when combined with its better known graphical user interface Toolkit — Tk. In 1997 Ousterhout was awarded the ACM Software System Award for Tcl/Tk, an award given to institutions or individuals recognized for developing software systems with a lasting influence, reflected in contributions to concepts, in commercial acceptance, or both.

↫ Armen Barsegyan

Everything you could ever possibly want to know about Tcl/Tk. There’s nothing to add here; if this is up your alley – and you know if it is – just go ahead and read it, and stop wasting time here.

That is the first line of the 80s microcomputer BASIC game The Wizard’s Castle initially written for the Exidy Sorcerer platform.

It’s a REMark statement, a comment in that particular language. 10 is the line number, if you’re unfamiliar with languages that had such things.

But the interesting part was this "_(C2SLFF4 mess. A typo or garbage? No. It appears verbatim in the source code as originally published in the July, 1980 issue of Recreational Computing.

What the heck is it?

↫ Brian “Beej” Hall

A fun investigation to brighten up your Monday.

This post is about the evolution of Futhark’s type checker, motivated by a large refactoring I am about to merge. It is probably mostly of interest to other language designers, and contains some lessons I wish I had known when we first got started – although I am not particularly well-read in the type checking literature, so it’s possible all of this is old hat.

↫ The Futhark Programming Language blog

That’s a clear introduction – you know what to expect.

What happens when programmers get to vote on a complete ban on slopcoded software on their code platform? Members of Codeberg were asked to vote on a proposal to completely ban slopcoded projects from Codeberg, and in what should not be a surprising outcome to anyone not overcome with “AI” hysteria, the vast majority voted in favour of the complete ban: over 70% of Codeberg members voted to ban slopcoded projects entirely (358 in favour, 144 against, 14 abstentions).

Of course, this is not a surprising outcome. Stripped down, programming is a form of artistic expression, and programming is no different than writing, painting, composing, or any other artistic endeavour. I think it’s safe to say writers, painters, composers, and similar creatives are against “AI”, so it’s only natural programmers feel the same; poll after poll shows the overwhelming majority of respondents – usually well over 70-80% – are against “AI”.

The pro-“AI” accounts on OSNews often try to paint my anti-“AI” position as extremist, but in reality, I’m just voicing how 70-80% of people clearly state they feel. I have zero skin in this game, zero outside pressure to please any bosses to get that promotion, zero pressure to conform to avoid getting laid off, zero pressure to not contradict upper-management. I can speak freely, openly, and without fear of retaliation. And as Nikhil Suresh explains in his harrowing from-the-trenches article AI Mania Is Eviscerating Global Decision-Making, that’s a massive asset.

The vast majority of people – including your friends, family, and co-workers – really hate “AI”. You can either accept this, or be left behind.