ProofID blog

2027 State of Agentic AI Readiness: Adoption Without Control | ProofID

ProofID — Tue, 06 Oct 2026 12:02:04 GMT

Agentic AI is scaling faster than the controls around it

Agentic AI has already moved from experiments into everyday operations for many organisations. Governance, however, is really struggling to keep pace.

New research by ProofID and Coleman Parkes, based on a survey of 300 enterprise decision-makers and influencers across the US, UK and Europe, shows how quickly adoption is moving. Almost 1 in 5 organisations already has agentic AI in production, while a further 47% expect to deploy it within the next 12 months.

But those headline numbers only tell part of the story. Every organisation surveyed reported some use of agentic AI. Among those without sanctioned production deployments, 43% said informal use was already quite extensive. This means a lot of agentic AI activity is already happening outside of formal deployment initiatives.

This can leave a significant blind spot. If you’re waiting for a formal production rollout before putting governance and control in place, you may already be living with agent activity you haven’t accounted for.

As agents become capable of accessing systems, using tools and taking actions with limited human intervention, you need to answer five fundamental questions:

Discover: What agents exist across your organisation?
Govern: Who owns each agent and its lifecycle?
Connect: How does each agent interact with systems and services?
Trust: What identity and permissions does each agent have?
Observe: Can you see and intervene in what an agent is doing?

These aren’t five separate boxes to tick. They all depend on each other. You can’t govern an agent you haven’t discovered, control its access properly without a reliable identity, or respond effectively if you can’t see what it’s doing.

The objective is to make autonomy controlled, accountable and scalable.

Five pillars for agentic AI readiness

Our research points to five connected areas organisations need to address as agentic AI moves from experimentation into production.

1. Discover: Know what is operating

You cannot control what you cannot see. AI agents can enter your environment through sanctioned platforms, embedded capabilities, internal development and third-party tools. That makes visibility harder than it might first appear.

Only 22% of organisations surveyed maintain a complete central repository of their agents, while 40% are not confident they know every AI agent operating within their organisation.

Discovery isn’t a one-and-done job. Before you can decide whether an agent is appropriately governed or secured, you first need to know that it exists – and keep knowing as your agent estate changes.

2. Govern: Establish accountability

As agents take on more autonomous roles, you need clear accountability for how they operate, the decisions they enable and what happens throughout their lifecycle. Somebody needs to own each agent from the point it is introduced through to when it is retired.

The research found that 86% of organisations do not assign a human accountable for every agent, while only 14% have formal onboarding, offboarding and periodic re-certification processes for every agent.

Without a clear owner, a manageable experiment can quickly turn into an enduring control gap. Good governance puts the accountability and lifecycle discipline around agentic AI that you need if you’re going to scale it safely.

3. Connect: Control how agents interact

What an agent can reach shapes what it can affect. The more systems, tools and data it can interact with, the greater the potential impact of its actions.

If those connections are controlled differently from one system to the next, it becomes much harder to understand and limit that impact.

As many as 81% of organisations lack organisation-wide standards for agent integrations, while 88% do not route all agentic AI traffic through a central AI or MCP gateway.

As your agent estate grows, fragmented integrations can leave you with a patchwork of authentication, policy, logging and intervention mechanisms. Standardising how agents connect to enterprise systems gives you a much stronger foundation for applying control consistently.

4. Trust: Give agents an identity

For identity teams, the question is straightforward: which agent is acting, what is it authorised to do and how is that authority being controlled?

According to the research, only 17% of organisations give every AI agent a unique authenticated identity. Meanwhile, 52% report that many or all agents use shared credentials, shared identities or unmanaged identities.

Without a distinct identity, it becomes much harder to say with confidence which agent did what, or to apply access controls precisely. As the actor shifts from a person to an autonomous system, your approach to identity and access has to shift with it.

5. Observe: Make visibility actionable

Seeing activity is one thing. Being able to act on it quickly is what makes that visibility useful.

When autonomous systems can take actions without direct human intervention, you need to spot potentially risky or unauthorised behaviour quickly and intervene before the consequences spread.

As many as 82% of respondents lack full, real-time, organisation-wide visibility, and only 22% can automatically terminate a rogue agent in real time.

For systems capable of taking multiple actions in seconds, simply collecting activity data isn’t enough. You need enough context to understand what an agent is doing, whether it is still operating within its authorised boundaries and, crucially, the ability to step in quickly when it isn’t.

From adoption to controlled autonomy

Agentic AI adoption is accelerating, but our research suggests that organisational control is not advancing at the same pace.

Giving agents room to act doesn’t mean giving them free rein. As adoption scales, the boundaries around that activity need to keep pace.

That means treating discovery, governance, connectivity, identity and observation as connected disciplines rather than separate security tasks. As your agent estate grows, you need to know where agents are being used, how much authority they have, who is accountable for them and whether you can see – and stop – what they are doing when necessary.

The full 2027 State of Agentic AI Readiness report explores what 300 enterprise decision-makers told us about agentic AI adoption, visibility, identity, governance and real-time control, and examines the five pillars organisations need to build a more controlled and scalable agentic AI estate.

Download the full report to explore the research, findings and five pillars in more detail.

People, Process & Technology: Agentic AI Discovery | ProofID

Neil Evans — Fri, 02 Oct 2026 08:00:00 GMT

While AI may be revolutionary, the way people are adopting it isn't. We've seen this before with technologies such as mobile and remote working tools. When something is easy to access and helps people get their jobs done quicker, adoption often moves faster than the governance around it.

That makes shadow AI as much a cultural challenge, as a technical one. If people assume security will effectively “say no”, they're less likely to tell you what they're doing. In most cases, they don’t have bad intentions. They just want to use AI to work more efficiently or solve a problem their existing tools can’t.

New research by ProofID in conjunction with Coleman Parkes shows the scale of the challenge. As many as 40% of organisations are not confident they know every AI agent operating within their business, while only 22% maintain a complete central repository of their agents.

Every organisation surveyed believes agentic AI is already being used informally somewhere in the business, and among organisations without sanctioned production deployments, 43% describe that informal use as quite extensive.

That is why people and culture have to come first. If employees feel able to raise a new AI use case early, you can assess it before it becomes another act of shadow AI. The process needs to make that easy, while technology should help to uncover the tools and agents people haven’t declared.

Start with culture: make disclosure easier

Employees are adopting AI because it helps them get work done and that reality should shape how organisations approach shadow AI.

Someone experimenting with an AI tool is not necessarily attempting to circumvent your security controls. They may have found a way to summarise documents more efficiently, automate repetitive work, or complete a task that your current systems handle poorly. If the response from security teams is an automatic prohibition, that employee has a strong incentive to keep their experiment out of sight. The harder the approved route becomes, the more attractive the unapproved route looks.

So, if security becomes the “computer says no” department, the experimentation doesn't stop. It simply becomes harder to see.

A better approach is to create an environment where an employee can say, “I've found something useful and I want to try it,” without assuming that the immediate response will be a refusal. That does not mean removing security controls completely or allowing unrestricted experimentation but instead making the safe route practical, understandable and proportionate.

Not every experiment needs the same level of scrutiny. Trying a tool with public information is very different from giving an agent access to production systems, sensitive data or the authority to make decisions. Your process should absolutely reflect that difference.

Employees should understand what the organisation's AI policy means, which tools and use cases require approval, what information should not be put into an AI system and where to go for guidance. Just as importantly, they should understand that declaring an AI tool or agent starts a conversation rather than automatically ending an idea.

The aim is to build a culture where people feel comfortable putting their hand up early. When they do, you get something technology cannot reliably provide on its own: context. You can understand why the technology is being used, the problem it is solving and what someone is trying to achieve. That makes it easier to decide whether an experiment should be formalised, controlled more tightly or stopped.

Put a process in place to support openness

Culture creates the willingness to disclose information about AI agents, but a planned process turns that willingness into something your organisation can manage. The registration process for a new AI agent needs to be straightforward enough that employees and developers will actually use it.

This process has to support the culture you're trying to create. If every new idea faces the same lengthy approval route regardless of the risk involved, that approval route quickly becomes harder to use than it needs to be.

A practical approach should aim to establish:

Who owns the agent
What is it intended to do
Which systems and tools can it access
What data it handles
How it authenticates
How much autonomy it has
What controls are available if something goes wrong

Our research suggests that this lifecycle discipline is missing in many organisations. Only 14% of organisations have formal onboarding, offboarding and periodic re-certification processes for every agent, while 36% describe their lifecycle processes as informal or evolving.

Governance still needs to be there, but it should match the risk of the use case. A routine assistant working with low-risk information can be managed differently from an agent handling sensitive data or taking a high-impact action, where stronger controls or human approval may be appropriate.

A further challenge is that agents change after deployment. Models can change, tools can be added, permissions can expand and new data sources can be connected as business requirements evolve.

As a result, the register needs to remain current, with onboarding, material changes, periodic review and retirement connected to the same governance process. When an agent is no longer required, its identity, permissions and integrations should be removed. The goal is to have a maintained view of your organisation’s AI estate that supports real security decisions.

The discovery problem is bigger than sanctioned AI

Traditional technology inventories are built around systems that organisations deliberately acquire, deploy and manage. But agentic AI can enter the environment through much less formal routes.

AI agents can emerge across the enterprise in more ways than organisations may realise, including:

Sanctioned AI platforms: approved, deployed and managed by IT as part of the organisation’s formal technology estate.
Embedded AI capabilities: introduced through existing business applications, where new functionality can appear without being treated as a separate agent.
Internally developed agents: built by development or business teams to automate specific workflows, tasks or decisions.
Consumer or third-party tools: adopted by employees to solve business problems, sometimes without formal approval or visibility from IT and security teams.
Software updates: that introduce new AI functionality into existing platforms without anyone consciously deploying a new agent.

Each route creates a potential discovery gap, making it harder to know what is operating and what access or risk sits behind it.

At the same time, agentic AI can have considerably more operational reach than a conventional productivity tool. An agent may retrieve information, interact with APIs, call other tools or make changes within business systems, all at machine speed, turning an unknown AI capability into an unknown route into enterprise data and processes.

Use technology to find what people and processes miss

Even strong disclosure and governance processes will not capture everything in your AI estate. People forget to register tools, agents can be embedded within applications and software updates can introduce new AI functionality. This is where technology completes the picture.

In practice, there isn't one source of truth that will reveal your entire AI estate. You need to build the picture from several different sources. That might include identity and access systems, network monitoring, endpoint tools, browser telemetry, cloud and agent-platform inventories, application records and AI or MCP gateway logs.

The objective is to bring multiple signals into one operational view, allowing security teams to compare declared activity with observed activity and investigate any discrepancies.

Our research shows why this matters. Only 22% of organisations maintain a complete central repository, while 82% lack full organisation-wide real-time visibility. Technology can help close that gap by identifying activity that people and processes miss, validating what has been declared and providing evidence of how agents are actually operating.

Dedicated technology can add another layer. SailPoint Shadow AI Remediation, for example, provides real-time visibility and control over how employees use generative AI tools, alongside just-in-time remediation. That can help identify activity that hasn't been declared, but it still needs to sit alongside the right culture and processes, rather than replacing them.

This context matters because technical discovery can tell you what is happening, but not always why.

Better discovery creates room for more experimentation

The instinctive response to shadow AI is often to eliminate it, but that is increasingly difficult as AI becomes embedded in how people work and learn.

Eliminating experimentation shouldn't be the objective either. Much of the behaviour behind shadow AI is exactly what businesses say they want from their people: curiosity, innovation, greater productivity and finding smarter ways to work.

The organisation's job is to give that behaviour somewhere safe to go.

The answer is to make safe experimentation easier. This starts with people who feel comfortable declaring what they are using, continues with processes that make registration and assessment proportionate to risk, and is reinforced by technology that identifies activity outside those processes.

Get the culture and process right and identity security becomes an enabler rather than a blocker. People know where to take an idea, while the technical controls help you identify what still falls outside that route.

Download the 2027 State of Agentic AI Readiness report to explore the latest research into Agentic AI readiness across 300+ organisations in the US, UK and Europe and the practical foundations for bringing your agentic AI estate under control.

ProofID is named one of the UK’s Best Workplaces in Tech™ | ProofID

Heather Chatten — Thu, 24 Sep 2026 09:04:51 GMT

I’m incredibly proud to share that ProofID has been named one of the UK’s Best Workplaces in Tech™ 2026 by Great Place To Work®.

It follows two consecutive years of Great Place To Work Certification™ and, while that was a fantastic milestone for us, this latest recognition feels particularly special.

That’s partly because of how the UK’s Best Workplaces in Tech™ list is put together. It’s based on what employees say, rather than what organisations say about themselves in an award entry. Great Place To Work® UK uses its research-backed Trust Index™ employee survey and analyses responses from UK-based tech employees to determine which organisations make the list.

Employees are asked about their experiences across areas including work-life balance, fulfilment, job satisfaction, psychological safety and financial security. The evaluation also considers how consistently organisations deliver a positive employee experience across different departments and levels of seniority.

In other words, this recognition is rooted in what our own people have told Great Place To Work about working at ProofID. For me, that’s what makes it so meaningful.

Why we started our Great Place To Work journey

Our Great Place To Work journey started long before we achieved our first certification. We already ran our own internal employee survey, but I wanted the independence and deeper insight that came from working with an external partner like Great Place To Work.

When we completed our first Trust Index survey in 2024, we were delighted with the response. The survey showed us where we were doing well and where our people wanted to see more from us.

We used that feedback to shape our priorities over the following year. That meant increasing our focus on performance development planning and professional development, taking another look at how our people viewed and understood our benefits, and holding employee sessions to help shape our approach to wellbeing and work-life balance.

When we ran the survey again in 2025, both our participation and Trust Index score increased, with particularly strong improvements around personal development.

In our latest survey, 83% of respondents said they would strongly endorse ProofID to friends and family as a great place to work, while 84% said they were offered training or development to further themselves professionally.

For me, that process is just as important as the result. There isn’t much value in asking people what they think if you only want to hear the positive bits. Each survey gives us an independent view of what’s working, where we’re making progress and where we still have work to do. age.

What it means to be one of the UK’s Best Workplaces in Tech™

Being recognised specifically as one of the UK’s Best Workplaces in Tech™ makes this an important milestone for ProofID. It places us among technology organisations whose employees report a consistently positive experience of their workplace.

We work in an industry that never stands still. The technology changes, the skills we need evolve and so do the expectations people have of their employers.

For ProofID to continue growing, we need an environment where talented people want to join us, build their careers and contribute to what comes next.

Tom Eggleston, CEO at ProofID, said:

'ProofID has grown significantly over the past few years, but we’ve always been clear that our people and culture are fundamental to that growth. Being recognised as one of the UK’s Best Workplaces in Tech is particularly meaningful because it reflects the experience of the people who work here every day. I’m incredibly proud of what the team has built together and excited about where we go next.'

Benedict Gautrey, Managing Director of Great Place To Work® UK, said:

'The technology sector continues to evolve at pace, with advances in AI and digital innovation reshaping the way organisations operate and people work. In an environment defined by constant change, the UK’s Best Workplaces in Tech™ demonstrate that a strong people-first culture is key to building confidence, connection, and trust.

Through purposeful investment in their workplace culture, transparent leadership, and a commitment to supporting their employees, these organisations create environments where people feel secure, valued, and empowered to embrace what comes next.'

What comes next?

Workplace culture isn’t something you finish.

As ProofID changes, the experience of working here will change too. New people join, teams grow and the things our employees need from us evolve. Our job is to keep listening and responding as that happens.

The survey will continue to tell us where we’re doing well, but just as importantly, where we need to do better. That’s what makes the process valuable and what will help us continue building on this recognition.

A Reason To Celebrate

Thank you to everyone at ProofID: you filled in the survey, but it’s your honest reflections that have helped us get here.

Two years of Great Place To Work Certification™ and now a place among the UK’s Best Workplaces in Tech™ reflect the experience you create for each other on the ordinary days, when no one is scoring it.

And if you’re an identity security professional reading this and wondering what it’s actually like to work at ProofID, don’t take my word for it. Take theirs.

The AI Extinction Debate Is Real. What Can We Actually Control? | ProofID

Matthew Berdine — Fri, 18 Sep 2026 14:21:41 GMT

A few weeks ago, a researcher named Jacob Coxon left Anthropic and went public with a warning most of us would rather not think about. CNBC reported that Coxon believes there is a greater than 10% chance AI causes the extinction of humanity, and he isn't alone. A colleague of his, Anthropic alignment lead Evan Hubinger, has put his own personal estimate in that same range. Coxon pointed to incidents like a summer breach in which AI models circumvented isolation controls during routine security testing, and he warned that within six months to a year, the raw capabilities of these systems are going to get “quite scary”: superhuman hacking, help with bioweapons, autonomous systems operating with too little human oversight.

What made this impossible to wave off as one researcher's alarmism is what happened next. Anthropic's own CEO, Dario Amodei, sat down with Anderson Cooper on CNN, and when asked directly about Coxon's warning, he didn't distance himself from it. He said, in effect, that he agrees with Jacob much more than he disagrees with him. The head of one of the world's leading AI labs isn't dismissing the extinction scenario. He's engaging with it, while still arguing the outcome depends on the choices the industry makes from here.

Is all this alarmist? Maybe. Do these people making these statements have an agenda? Probably. But that doesn’t mean there isn’t a real risk associated with this technology. Any rapid advancement in technology comes with risk. Our job as security professionals is to calmly and reasonably assess risk and develop actionable remediations we can implement to manage it.

Whether you put the odds at 10%, 1%, or effectively zero, this isn't really an argument worth having from the outside. Nobody can currently prove or disprove a number like that, and it's not where the useful thinking is.

What's more interesting to me is this: the practical response looks basically the same regardless of which estimate you believe, and it's work our field already knows how to do. That's what I want to walk through.

The Pattern Worth Watching

I don't think the danger is an AI that wakes up one day and decides to kill everyone. The pattern I’d point people to is quieter than that, and in some ways more likely, because it comes from three ordinary properties of these systems stacking on top of each other.

First, AI can be extremely goal-focused. Give a capable model an objective and it will pursue it relentlessly, optimizing toward that goal in ways a person with broader judgment never would. Second, when AI is wrong, it is still very confident. These systems don't hedge the way an uncertain human does. A hallucinated fact or a flawed plan gets delivered with the same fluent certainty as a correct one. Third, unintended consequences have always been a risk in technology, but that risk is magnified with AI, because a model typically has less context and a narrower view of downstream effects than the humans it's acting on behalf of. It's optimizing for the objective in front of it, not for everything that objective might touch.

Put those three together relentless goal pursuits, unwarranted confidence, and a limited view of consequences and you get real potential for things to go very wrong very quickly. The Hugging Face incident Coxon cited is a small, contained preview of that pattern: models finding ways around isolation controls during testing, generating an abnormal volume of activity, not because anything was malicious, but because the system was doing exactly what it was optimized to do without the context to know it shouldn't.

That's the shape of the danger I'd point to: not an AI that intentionally sets out to harm us, but a capable, confident, narrowly-focused system that causes a catastrophe unintentionally, at a scale and speed that outpaces our ability to notice and correct it. Amodei's own comments about recursive self-improvement, and how quickly a coordinated swarm of AI agents could compromise infrastructure, point at the same thing: the risk compounds fastest when we're not watching closely enough.

We Are Not Powerless

All of that is genuinely unsettling. But here's the part of the story that gets less attention than the extinction headlines: we aren't powerless in the face of it.

We can't simply trust the AI companies to pace themselves and keep everything safe. Even Amodei, in the same interview where he validated Coxon's concerns, stopped well short of promising a safe outcome. He framed it as contingent on the industry making the right choices, not as something already handled. That's an honest answer, but it's not a plan the rest of us can just sit back and wait on.

It's worth noting how security professionals reacted to the Hugging Face incident Coxon pointed to as evidence of existential risk. Rather than treating it as proof of an unstoppable sci-fi scenario, researchers at firms like Trail of Bits and HackerOne described it as a familiar problem: inadequate monitoring and oversight controls that let abnormal activity go unnoticed for far too long. Their read was that better security practices are the more attainable place to start. Not because the bigger risks aren't real, but because we already know how to practice the discipline to address them.

That's the mindset I'd encourage. As security and identity professionals, we can each do our part to make sure whatever we're responsible for is safe and secure. We don't control what a frontier lab decides to release next quarter. We do control whether the AI agents in our own environment have more access than they need, whether their actions are logged and reviewable, whether there's a human in the loop before anything consequential happens, and whether the identity governing that agent can be revoked in seconds if it starts behaving badly.

In other words: we need to get back to basics. Least privilege. Strong authentication and identity governance for every human and every machine, including AI agents. Continuous monitoring that actually gets watched, not just collected. Segmentation and isolation controls that are tested, not assumed. Zero trust applied to AI the same way we've spent the last decade applying it to everything else. None of this is new. It's the first-principles work our field has been advocating for years — it just now applies to a category of actor that is faster, more confident, and less self-aware than anything we've secured before.

Whether you believe the extinction headlines are real or not, they point to a risk that deserves to be taken seriously. The response to these risks isn't panic, and it isn't waiting on someone else to solve it. It's the same discipline that's always separated organizations that get breached from organizations that don't, applied deliberately, and starting now, to the systems we're each responsible for.

How We Approach This

If you're working through this in your own environment, it's worth having a consistent way to break it down rather than tackling it ad hoc. We use a five-part model internally — covering discovery, ownership, access standards, scoped trust, and ongoing oversight — to work through exactly this kind of gap with clients, and it's a useful lens even outside a formal engagement.

What Anthropic’s Testing Failure Teaches Us About Identity | ProofID

Neil Evans — Mon, 14 Sep 2026 11:25:19 GMT

In July, I wrote about a set of OpenAI models that broke out of a test environment and hacked into Hugging Face, and argued that the lesson wasn’t really about clever AI — it was about the boundaries we build around what a model can reach. I didn’t expect the point to be proven again quite so quickly.

Prompted by that incident, Anthropic went back and reviewed its own cyber-capability tests. Across 141,006 evaluation runs, it found three cases where a Claude model reached the open internet from inside a test environment that was supposed to be sealed and went on to break into the production systems of three real organisations. The earliest dated back to April 2026. None of the affected organisations had noticed. Anthropic disclosed all of it publicly, in detail, and is working with the affected parties to put it right.

Two of the most capable AI labs in the world, nine days apart, both found the same failure in their own house. At the very least, that's enough to stop treating this as an isolated incident.

Same Lesson, Different Failure

The details matter, so it is worth being clear about what happened. Anthropic’s models were running capture-the-flag exercises which are a standard way to measure how good a model is at finding and exploiting weaknesses. The models were told, in their instructions, that they had no internet access and that everything around them was a simulation. That wasn’t true. Through a misconfiguration between Anthropic and the partner running the tests, the machines the models were working on did have live internet access. So, when a model went looking for its target and found a real company reachable on the open internet, it did what the exercise had asked: it treated that company as the target and attacked it.

There is a detail here that matters more than any other, and it is the one I’d ask you to hold on to. The OpenAI models needed a previously unknown vulnerability — a genuine zero-day — to escape their sandbox. Anthropic’s models needed nothing so sophisticated. They walked in through weak passwords and unauthenticated endpoints. In one case, a model read credentials straight off an exposed debug page and used a decades-old technique to reach a database of production data. No exotic exploit. No clever trick. Just doors that were left unlocked.

The Boundary Is The Control

That is the whole argument for identity, made better than I could make it. The breach didn’t depend on the model being brilliant. It depended on the boundaries being weak. When the controls around a system are loose enough, a capable agent doesn’t need to break in — it just walks through, and it does so at machine speed, without the pause a person might take to wonder whether they should.

It is worth being measured about what this proves, because the temptation to read it as rogue AI is strong, and it would be wrong. Anthropic is clear, and I think correct, that this was closer to a testing failure than a case of a model deciding to go off on its own. The models were told they had no internet access and were told to capture the flag; the environment was misconfigured to give them access they shouldn’t have had. They did the task they were set, under a false belief about where they were. That is not a machine turning on us. It is a machine doing exactly what it was told, in an environment where the boundaries didn’t hold which, if anything, is the more useful lesson, because it is the one we can actually design for.

The response, then, is not a cleverer guardrail inside the model. It is the same discipline I wrote about a month ago, and it is the discipline Anthropic itself reached for in its own conclusions: the environment around the model has to be treated as something that needs securing, to the same standard as any production system. A capable agent will use whatever path is open to it. If a path exists that shouldn’t, the agent will find it — not out of malice, but because finding paths is the job you gave it. Every one of these incidents ran into a control that identity and access security already knows how to build; tight boundaries on what an identity can reach, authorisation decided at the moment of action, and honest observation of what the agent actually did. The door, the floor, and the checkpoints in between.

How The Harm Spreads

There is one more detail worth sitting with, because it points at where this is heading. In one of the incidents, a model tried to win its challenge by publishing a software package to a public registry — the kind of shared library that developers everywhere pull into their own systems without a second thought. The package was live for about an hour. In that hour, fifteen real machines downloaded and ran it. One belonged to a security company whose scanner routinely installs packages to check them for exactly this kind of thing; when it did, the model’s code ran and quietly took that company’s credentials. The model didn’t target that company. It didn’t know the company existed. The harm simply spread, the way anything published to an open system spreads, to whoever happened to trust it.

Old Problems, New Evidence

I’ve spent much of my career in enterprise information management and regulated industries, where the question “who, or what, is allowed to touch this, and how do we know?” has never been optional. That question is the whole of this. It applied to human users and service accounts for years; it applies to autonomous agents now, and it applies with more force, because an agent can exercise every permission you give it, faster than you can watch, and without stopping to ask whether it should.

AI will keep getting faster, more capable and more autonomous. Whether it also becomes safe to rely on is a choice we make, in how we design the systems around it, what we let each identity reach, and how clearly we can see what it does.

Two labs have now given us versions of the same warning within a matter of weeks: the model isn't where the control lives. The control lives in the architecture around it.

We've explore AI identity foundations in more detail in our Five Pillars for Agentic AI Identity Security framework, including how organisations can discover, govern, connect, trust and observe AI agents. Trust isn't a feature you bolt on at the end. It's the first one. Architecture first, speed second.

What an AI breaking into Hugging Face teaches us about control | ProofID

Neil Evans — Fri, 24 Jul 2026 12:15:42 GMT

Every so often an incident turns an abstract debate into something tangible, confirming something a lot of us have been thinking for a while. This week’s OpenAI and Hugging Face incident did exactly that.

A set of OpenAI models being evaluated in an internal cyber-capability test did something nobody instructed them to do. They broke out of the sandbox they were being tested in, found their way onto the open internet, and hacked into the production infrastructure of another company, Hugging Face. They weren’t trying to cause harm: they were trying to win. The test had an answer key, the models wanted it and reasoned it might be sitting on Hugging Face's systems, so they went and took it. Both companies have since disclosed the incident and are investigating it together in the open, which deserves credit.

More Than Just Another AI Incident

The details matter more than the headline, so it is worth looking at what actually happened. OpenAI was measuring how good its models were at finding and exploiting vulnerabilities. To measure the upper limits of that capability, the team deliberately turned off the safety guardrails that would normally refuse this sort of activity. That decision is central to understanding what happened next. With the brakes off, the models found a previously unknown vulnerability in a piece of infrastructure inside the test environment, used it to escape, escalated their privileges, moved sideways through the network until they reached a machine with internet access, and then set about the target. On the Hugging Face side, they got in through the data-processing pipeline, harvested credentials, moved across several internal clusters over a weekend, and in one instance chained stolen credentials and fresh vulnerabilities together to reach a production database. The whole campaign ran as an autonomous swarm, executing many thousands of individual actions at machine speed.

It's worth being measured about what this does and doesn’t prove, because the temptation to over-read it is strong and both companies have a commercial interest in how the story is told. This wasn’t a rogue intelligence deciding to go to war. It was an AI doing exactly the dangerous thing it was being tested for, more thoroughly than anyone expected, in an environment where the safeguards had been switched off on purpose. Strip away the drama and something quieter and more useful is left: a real-world demonstration that you cannot rely on the AI models themselves to stay within the lines. When they don’t, the only thing standing between a curious machine and your production database is the strength of the boundaries you’ve built around what they can reach.

Security Starts Outside The Model

For me, that’s the real lesson from this incident, and it’s not a new one. It’s the principle underneath the five pillar identity security framework we published earlier this month. You can’t prevent a sufficiently capable model from doing something you did not intend, whether that comes from a prompt injection buried in a document or, as here, from a model gaming its own objective. Prevention at the model layer is not a control you can bank on, because the model layer sits outside your control.

What you can do is contain the blast radius.

Every stage of this incident reinforces why identity controls matter. The escape crossed a boundary that should have been a hard enforcement edge. The lateral movement was a series of actions that runtime authorisation should have been interrogating, one by one. The distance the models travelled was a direct function of how widely the permissions around them had been drawn. The reach into the database was a question of data access governance — of whether an identity, human or machine, should have been able to touch that data at all. These aren’t new controls invented for the age of AI. They’re just the door, the floor, and the checkpoints in between, applied with more rigour than we’ve historically bothered with. The same identity principles we’ve been using for years, albeit perhaps not stringently enough in some cases.

You Can't Watch The Mind

There's a second lesson here, and it is the one that stands out most to me. The models' reasoning, choosing a target, planning the intrusion, was invisible while it was happening. Nobody caught it in the moment by reading the machine's mind, because that simply isn’t possible. What caught it was the trail of actions left behind; more than seventeen thousand recorded events that Hugging Face was able to detect and reconstruct after the fact. You can’t watch the mind, so you have to watch the hands. Observability for autonomous systems lives at the layer of what they do, not what they think. Anyone who’s run production systems in a regulated industry already knows this, which is why we keep immutable audit trails rather than trusting a process to report on itself.

Old Problems, Faster Machines

There is an uncomfortable note in all this. Agents expose how thin some of our governance always was. I’ve spent much of my career in enterprise information management and regulated industries, where governance, identity and observability have never been optional. That’s one reason this incident feels familiar – none of the controls it highlights are new. We’ve simply tolerated over-broad permissions, standing access, and weak boundaries for years, because there was always a human in the loop.

Remove the human, hand the same access to a machine that acts a hundred times faster and does not stop to ask whether it should, and the shortcuts we lived with become the vulnerabilities we regret. The work required is work we already know how to do; tight entitlements, least privilege that is actually enforced, well governed identities, authorisation decided at the moment of action, and honest observation of what agents actually do. The organisations that take this seriously now, while the examples are still happening to other people, will be far better prepared when these incidents move from isolated examples to everyday operational risks.

AI will continue to become faster, more capable and more autonomous. That's inevitable. Whether it also becomes trustworthy is a choice organisations make through the way they design, govern and secure it. That starts with strong identity foundations, clear ownership, well-defined access boundaries and a deep understanding of where your data lives and who, or what, should be able to reach it. Get those foundations right, and you give AI room to innovate safely. Ignore them, and you'll spend your time reacting to the next incident instead of preventing it.

We've explored these identity foundations in more detail in our Five Pillars for Agentic AI Identity Security framework, including how organisations can discover, govern, connect, trust and observe AI agents. Trust isn't a feature you bolt on at the end. It's the first one. Architecture first, speed second.

5 Questions To Ask To Prepare For 100-Day TLS Certificates | ProofID

Patrick Maginn — Thu, 23 Jul 2026 09:52:57 GMT

The shift to shorter TLS certificate lifetimes is already underway

Since March 2026, newly issued public TLS certificates have a reduced lifetime of 200 days. That reduction was only the start of a much greater change. From 15 March 2027, certificate lifetimes fall again to 100 days, meaning every public-facing certificate will need renewing around 3.7 times a year. Eventually, in 2029, certificates will be valid for a maximum of 47 days.

For organisations still relying on manual processes, spreadsheets or partial visibility, that doesn't just increase the workload. It increases the opportunities for something to be missed.

For teams that are already stretched, the next decrease will be here in no time. Before the deadline arrives, it's worth asking some honest, practical questions about how ready your organisation really is, and starting the work now rather than waiting as we’ve seen how long it can take.

1. Do you know where all your certificates are?

Most organisations think they know where all their certificates are until they run a proper discovery scan. In fact, DigiCert's 2026 Global PKI Research found that only 34% of organisations have a complete and current view of their certificate estate. Manual tracking methods, including spreadsheets, remain one of the biggest challenges teams face.

Having a certificate inventory is a good start, but the real test is whether you have continuous, automated discovery across every public-facing certificate, including those protecting legacy websites, acquired domains or applications that no longer have a clearly defined owner.

What this looks like in practice:

Run a full external attack surface scan against every domain and subdomain you own, not just the ones sitting in your CA portal.

Reconcile that scan against your CMDB or asset inventory. Most gaps surface here first.

Assign a named owner to every certificate you find, not just every certificate someone remembers issuing.

Make discovery an ongoing process rather than a one-off audit. Shorter certificate lifetimes mean your inventory will become outdated far more quickly.

2. Is your renewal process ready for shorter certificate lifetimes?

A manual renewal typically involves validating ownership, generating a new private key, creating a CSR, requesting the certificate, deploying it and testing everything is working as expected. For many organisations, that's around four hours of work for a single certificate.

With 100-day certificate lifespans, that work no longer happens once a year. It happens around 3.7 times. Across an estate of a thousands of public certificates, that's thousands of additional hours of repetitive manual work every year, all of it landing on teams that typically aren't getting any bigger to handle the increased load. I recently looked at what this means in real terms, including the impact on renewal volumes and operational effort, you can read it here: The Cost of TLS Certificate Renewals.

The question is no longer whether automation is worthwhile. It's whether you can reduce renewal time from hours to minutes before the increase in volume arrives.

What this looks like in practice:

Time an actual renewal end to end, including CSR generation, deployment and testing. Don't estimate it.

Multiply that figure by your certificate count and the new renewal frequency to get a real hours-per-year number.

Compare that number honestly against the headcount you realistically have free for this work.

Identify which certificates can move to automated, policy-driven renewals today, and which genuinely still need a human in the loop.

3. Would a certificate failure show up on your radar before it causes an outage?

CyberArk's 2026 PKI Modernisation Report found that 56% of organisations have experienced unplanned outages caused by expired or misconfigured certificates. While today's certificate lifetimes are still relatively generous, the transition to 100-day and eventually 47-day certificates will significantly increase the number of renewals organisations need to complete each year. Every additional renewal is another opportunity for something to be missed.

The question is whether you'll know about a failed renewal before your users do. That depends on more than expiry notifications. It means integrating certificate management with your monitoring, ticketing and operational workflows so failures are detected, escalated and resolved before they become production incidents and impact reputation and revenue.

What this looks like in practice:

Confirm expiry alerts fire to a monitored, owned queue, not an inbox that one person happens to read.

Test what happens when a renewal fails partway through. Does anyone find out before the certificate actually expires?

Map your highest revenue and highest risk services, then check they have tighter alerting thresholds than lower-priority systems

Run a tabletop exercise on an expired certificate. Time your actual detection and remediation. Don't assume it.

4. Are you confident every certificate on your estate is compliant?

Research from Enterprise Management Associates (EMA) found that nearly 80% of SSL/TLS certificates in use were still potentially vulnerable to man-in-the-middle attacks, largely because the associated servers were not using TLS 1.3. The same research found that up to 25% of certificates were expired or self-signed, creating further security and trust risks.

As certificate lifetimes shorten, organisations will be issuing and deploying certificates more frequently. Without automated policy checks, that creates more opportunities for weak algorithms, unapproved certificate authorities or incomplete chains of trust to make it into production. It also creates more opportunities to identify and correct those issues, provided validation is built into the renewal process.

That raises an important question: are you automatically validating certificate attributes such as key length, signing algorithms and chains of trust while restricting issuance to approved certificate authorities?

What this looks like in practice:

Define a certificate policy covering key lengths, signing algorithms, validity periods and approved certificate authorities, then enforce it at issuance.

Check whether any certificates on your estate are self-signed or issued by an unapproved certificate authority.

Make sure every renewal automatically re-validates compliance, rather than assuming nothing has changed since the certificate was first issued

Automatically generate compliance evidence for standards such as NIST, ISO 27001 or PCI DSS, rather than assembling it manually ahead of an audit.

5. Is your infrastructure built for where this is heading, not just where it is now?

The move to 100 day certificate lifetimes is a milestone, not the end point. By 15 March 2029, every public TLS certificate will need renewing almost eight times a year. That’s every 47 days.

The real test of readiness isn't whether you can meet the 100-day deadline next year. It's whether the approach you put in place today will still work as certificate lifetimes continue to shrink and cryptographic standards evolve. That means building automation that can scale with future certificate lifetime reductions, while ensuring your infrastructure is crypto-agile enough to adapt to future cryptographic changes, including post-quantum cryptography.

Only 22% of organisations say they've fully assessed their systems for future cryptographic risk (DigiCert 2026 Global PKI Research). For most organisations, the challenge extends beyond shorter certificate lifetimes. It's about building a certificate management strategy that's resilient enough to support whatever comes next.

What this looks like in practice:

Choose tooling built for continuous automation, not a stopgap patched together to clear the 100-day deadline alone.

Ask your certificate management vendor directly how they support crypto-agility and post-quantum algorithms, and get a specific answer.

Build renewal automation once and apply it across every future lifespan reduction, rather than re-engineering for each new deadline.

Put 2029 on your roadmap now as a key focus, not on your successor's to-do list.

The Bottom Line

Most organisations don't need to solve every challenge overnight. But they do need to understand what they own, where manual effort is creating unnecessary risk, and where automation will have the greatest impact. The earlier that work begins, the easier each future lifespan reduction becomes.

A practical place to start is thoroughly identifying and mapping your estate. ProofID, together with CyberArk, offers a complimentary scan of your public TLS certificates, that will give you a clear view of your external certificates and help you prioritise the work ahead.

Once you've received your results, you'll have the opportunity to book a complimentary strategy session with our certificate lifecycle management experts. They'll walk you through the findings, discuss your current approach and help you build a practical roadmap for managing shorter certificate lifecycles with confidence.

From there, the path is straightforward:

Securing Agentic AI Without Slowing Down Innovation: Fireside Chat

ProofID — Wed, 15 Jul 2026 14:55:13 GMT

Agentic AI Identity Security: 5 Pillars for Scaling AI Agents

ProofID — Tue, 14 Jul 2026 12:00:04 GMT

Why Agentic AI Creates a New Identity Security Challenge

Agentic AI is moving from experimentation into enterprise operations as organisations look to improve efficiency, increase output, accelerate decision-making, and scale automation. But as agents are given access to systems and data, they create a new identity security challenge.

Unlike traditional software, AI agents can reason, plan, initiate actions, and adapt their behaviour based on changing inputs. Recent IBM research found that only 11% of technology leaders feel completely prepared for AI agent deployment at scale, while surveyed organisations experienced an average of 54 AI agent incidents last year.

From an identity perspective, the issue’s straightforward: if an agent can access data or act across connected systems, it needs to be treated as an identity. That means knowing who owns it, what it’s allowed to do, and how its behaviour will be controlled over time. In practice, this gets difficult because AI adoption doesn’t always follow a centralised path. Agents can enter the environment through everyday tools and workflows before security teams have full visibility of where they’re operating.

The result is a growing layer of unmanaged AI activity. This is where Shadow AI starts to emerge, as agents and AI-enabled tools are adopted without proper oversight. Organisations can’t secure what they can’t see, and they can’t scale what they can’t control — which is why identity security has to become the foundation for Agentic AI readiness.

Identity Security: The Foundation for Agentic AI Readiness

At their core, AI agents are non-human identities. They’re not human users, but they still need to be governed as identities because they can access systems, retrieve data, trigger workflows, and take action.

They sit closer to machine identities than human identities, but autonomy changes the risk. AI agents can act at speed, adapt to changing context, and make decisions across connected systems.

That’s why organisations need to slow down enough to speed up safely. Before AI agents scale across workflows, applications, and data sources, they need identity foundations that protect visibility, control, and accountability.

At ProofID, we organise that approach into five foundational pillars:

Discover
Govern
Connect
Trust
Observe

By combining these pillars, we establish the identity security foundation needed to operationalise Agentic AI safely and at scale.

The Five Pillars of Agentic AI Readiness

The five pillars of Agentic AI readiness provide a framework for securing and scaling AI agents as non-human identities:

Pillar	Purpose
Discover	Identify all AI agents, understand where they operate, and map their interactions across the environment.
Govern	Establish ownership, lifecycle management, policies, and accountability for every AI agent.
Connect	Build consistent, secure connections between AI agents and the systems, data, and tools they need to reach.
Trust	Make real-time authorisation decisions based on context, risk, and least-privilege principles.
Observe	Continuously monitor agent behaviour, detect anomalies, and intervene when necessary.

Together, these pillars create the foundation necessary to implement Agentic AI safely and confidently.

Pillar 1: Discover

You Can’t Govern What You Can’t See

Every security programme begins with visibility. Before organisations can secure AI agents, they need to understand where they exist, what they’re connected to, and how they interact with enterprise resources.

This sounds straightforward, but AI visibility gaps are already emerging. Business teams are adopting AI tools independently, developers are creating autonomous workflows, third-party applications are introducing embedded agents, and experimental projects can move into production without formal oversight.

The result is a growing population of AI identities operating outside established governance processes. This is where Shadow AI starts to emerge, as AI-enabled activity appears without formal visibility or control. To understand how well an organisation can discover and manage this activity, security leaders should ask:

How many AI agents are operating across your environment?
Can you identify unauthorised deployments?
Do you understand which systems each agent can access?
Can you map agent-to-system and agent-to-agent interactions?

Without comprehensive discovery, every subsequent security control becomes more difficult to enforce. Visibility is the starting point for every other pillar.

Pillar 2: Govern

Every AI Agent Needs Ownership and Accountability

Discovery identifies which agents exist. Governance determines who’s responsible for them. Every AI agent in an organisation should have a clearly defined owner, a documented purpose, and a managed lifecycle. Without a named owner, an AI agent can become an unmanaged identity with persistent access and unclear accountability.

Best practice says employees shouldn't retain access indefinitely after changing roles or leaving the organisation, which is why most organisations run periodic certification campaigns to confirm access is still needed and still correct. AI agents need the same discipline. On a regular cycle, someone should be certifying that each agent is still doing the job it was created for, that its access still matches that job, and that it hasn't quietly picked up permissions it no longer needs. If an agent can't be recertified, that's the signal to retire it.

Governance should address:

Ownership assignments
Onboarding processes
Access approval workflows
Policy management
Periodic reviews and certification cycles
Retirement and decommissioning procedures

Many organisations are discovering that AI agents often outlive the projects they were created for. Without lifecycle controls, dormant agents can accumulate permissions, maintain unnecessary integrations, and create long-term security exposure.

Questions security leaders should ask include:

Who owns each AI agent?
Who approves its access?
How is its purpose documented?
When was it last certified?
What happens when it’s replaced or retired?

Governance establishes accountability and creates the operational structure required to manage AI at scale.

Pillar 3: Connect

Control Must Be Consistent Across Every AI Interaction

As organisations deploy more agents, complexity increases. New integrations form between applications, cloud services, data repositories, automation platforms, and emerging agent infrastructure such as MCP servers. Without the right architecture, these connections can quietly multiply into a tangle of one-off integrations, each built a little differently, each with its own gaps.

This is where thoughtful connection design matters. Organisations need shared, well-built pathways, such as secure gateways and common integration points, so that every agent reaches the systems it needs in the same trusted way, wherever that connection happens.

Connection capabilities should include:

Consistent integration patterns across environments
Shared authentication standards
Centralised connection points
Architecture that's designed to scale with confidence
The ability to adjust or close a connection quickly if something looks off

The aim is to make sure no agent's access depends on how one team happened to wire it up. Every agent should connect the same safe way, everywhere. Key questions to consider include:

Are AI agents connecting to systems in a consistent way across environments?
Can connections be managed centrally, rather than integration by integration?
Is access built on a shared standard, or does it depend on whichever tool or team set it up?

Without well-designed connections, governance is a good intention that never quite reaches the agents doing the work.

Pillar 4: Trust

Standing Permissions Are Not Appropriate for Autonomous Agents

Traditional access models often rely on standing permissions: access that remains in place until someone manually changes or removes it. That approach becomes increasingly problematic as AI agents gain autonomy. For autonomous agents, trust should be continuously assessed rather than permanently granted.

Agents operate continuously. They interact with multiple systems and their activities can vary significantly depending on context, data inputs, and business requirements. As a result, this demands a more dynamic trust model.

Organisations need real-time authorisation decisions based on current conditions rather than static assumptions. This includes:

Least-privilege access
Context-aware authorisation
Fine-grained permissions
Runtime policy evaluation
Continuous trust verification

Instead of simply asking whether an agent has access, organisations should evaluate whether the requested action is appropriate at that specific moment.

Important questions to ask include:

What can each AI agent access?
Under what conditions is access granted?
How are authorisation decisions evaluated in real time?

Trust provides the decision-making layer that allows AI agents to operate safely while maintaining business agility.

Pillar 5: Observe

AI Agent Visibility Can’t Stop at Deployment

Security doesn’t end when an AI agent goes live. In production, organisations need to understand not just whether an agent is active, but whether it’s behaving as expected. That means monitoring patterns of activity, detecting anomalies, identifying policy violations, and intervening quickly when behaviour moves outside agreed boundaries.

The speed of detection matters. If an AI agent behaves unexpectedly, the difference between a contained event and a serious incident may come down to how quickly the organisation can spot the change, understand what happened, and intervene.

As AI systems become more sophisticated, continuous oversight becomes increasingly important.

Observation capabilities include:

Behavioural monitoring
Anomaly detection
Audit trails
Compliance reporting
Incident response workflows
Intervention and containment mechanisms

To assess the ability to observe Agentic AI activity within an organisation, some critical questions include:

How quickly could unexpected AI behaviour be detected?
Can you trace the actions an agent performed?
Could you intervene before operational impact occurs?

Having the capability to observe and respond transforms Agentic AI security, allowing organisations to be proactive.

Reframing Identity Security as a Business Accelerator

Strong identity foundations help organisations move faster with Agentic AI because they create the confidence to scale safely. When security teams can evidence how agents are governed, AI adoption becomes easier to support and safer to expand.

They can confidently introduce new use cases faster, onboard additional agents more efficiently, and demonstrate accountability to regulators, auditors, customers, and executive stakeholders.

The key difference is the maturity of the identity foundation supporting Agentic AI. This creates the conditions for AI agents to be integrated into core business processes with predictable control and oversight.

Scaling AI with Control and Confidence

The shift from AI experimentation to AI operationalisation is already underway. AI agents are becoming active participants in business processes, application ecosystems, and enterprise decision-making. Their role will only expand as organisations pursue greater automation and efficiency.

Agentic AI is moving beyond experimentation and into the systems, workflows, and decisions that keep the business running. The question for technology and security leaders isn’t simply whether AI agents will become part of the enterprise environment. It’s whether the organisation can see them, govern them, control what they can do, verify when they should be trusted, and respond when behaviour changes.

Those identity foundations are what turn Agentic AI from an unmanaged risk into something the business can scale with confidence.

How prepared is your organisation to scale Agentic AI securely? Assess your maturity across the five pillars of Agentic AI readiness — Discover, Govern, Connect, Trust, and Observe — and identify the gaps that could limit your ability to expand AI initiatives with confidence.

Take the Agentic AI Readiness Assessment to benchmark your maturity across the five pillars and identify the gaps that could limit secure AI adoption.

Neil Evans Appointed as Chief AI Officer | ProofID

ProofID — Thu, 09 Jul 2026 09:28:21 GMT

Newly created senior leadership role blends commercial, technical and people leadership to embed an AI-native mindset across the business.

ProofID, the pure-play identity security specialist delivering advisory, implementation and managed services, today announced the appointment of Neil Evans as its first Chief AI Officer. The newly created role will lead ProofID's transformation into an AI-native business — building AI-native delivery capabilities internally, developing new AI-powered service offerings for customers, and positioning ProofID as the recognised leader in AI-enabled identity services across EMEA and the Americas.

The appointment comes at a critical time for enterprise technology. Organisations across every sector are racing to deploy AI, embedding autonomous agents, accelerating workflows and integrating AI tools across their operations. That shift is creating an entirely new identity challenge, as organisations look to secure, govern and monitor autonomous AI agents with the same rigour as their human workforce.

Evans brings more than 30 years of technology leadership spanning software engineering, product innovation and C-suite roles across enterprise software and professional audio. He most recently served as Cloud & Mobile Engineering Leader at Music Tribe's Midas Division and previously spent five years as CTO (EMEA) at UNICOM Global, directing emerging technology strategy across natural language processing, AI, machine learning and blockchain. He holds a Master of Engineering in Microelectronics Systems Engineering from the University of Manchester.

“This is a people-first transformation as much as a technical one,” said Tom Eggleston, CEO of ProofID. “Technology is the enabler, but it's the mindset, behaviours and capability of our people that will determine whether we succeed in becoming AI-native, while staying true to who we are — the identity security specialist our customers already trust. Neil has spent his career leading exactly that kind of change, and he's the right person to drive it end-to-end.”

The Chief AI Officer role is a commercial, technical and people leadership position in equal measure. Evans joins ProofID's senior leadership team and will lead the cultural and behavioural change needed to embed an AI-native mindset across the business, alongside building the new capabilities and offerings that will define ProofID's proposition in the market. The role builds on ProofID's existing Agentic AI Enablement advisory practice, which helps organisations secure autonomous AI agents using their identity investments.

“This is a rare opportunity to lead a transformation from the inside — not just advising clients on how to become AI-native, but building that capability into ProofID itself,” said Neil Evans, Chief AI Officer at ProofID. “The technology is the easy part. The real work is bringing our people with us, so we can deliver AI-powered identity services at the level our customers expect.”

Preparing for Agentic AI?

As organisations adopt autonomous AI agents, identity becomes the foundation for secure, scalable deployment. Discover how ProofID helps organisations secure, govern and enable Agentic AI with confidence.