" " indicates required fields
Artificial intelligence is changing the way we think about trust.
Every day, AI-generated images, videos, audio recordings, emails, documents, software and social media content are becoming more convincing and more difficult to distinguish from human-created material.
But the conversation around AI trust is also changing. What was recently a largely technical debate about deepfakes and synthetic media is rapidly becoming an issue of governance, cybersecurity and regulatory compliance.
On August 2, 2026, the transparency provisions of Article 50 of the EU AI Act became applicable. Among other requirements, providers of covered AI systems that generate synthetic audio, image, video or text must ensure that outputs are marked in a machine-readable format and detectable as artificially generated or manipulated. Deployers also face disclosure obligations around deepfakes and certain AI-generated or manipulated text on matters of public interest. A limited transitional period applies to the marking obligation for certain generative AI systems placed on the market before August 2, 2026.
That is an important milestone, and it also points to a much bigger issue underneath it.
In a world where almost anything can be generated, replicated or manipulated by AI, how do we establish trust?
Much of today’s discussion still focuses on whether content is “real” or “fake.”
Deepfake detection, watermarking, AI-content detection and authentication technologies all have important roles to play. But they address only part of the challenge.
The question is no longer whether AI can create convincing content. It clearly can.
The more important question is whether we can establish enough evidence around that content to decide whether we should trust it.
That distinction matters because AI-generated does not necessarily mean false, and human-generated does not necessarily mean trustworthy.
A company can intentionally create an AI-generated training video that is completely legitimate. A human can write a fraudulent email without using AI at all. A photograph can be genuine but presented with a false description. An AI-generated document can contain accurate information. A legitimate piece of software can contain a critical vulnerability.
Authenticity and trust are related, but they are not the same thing.
As AI capabilities improve, relying solely on analysis of the final output becomes increasingly difficult. Detection technologies will improve, generation technologies will improve, and the cycle will continue.
Trust therefore needs another layer.
Provenance.
For decades, trust was often based on observation.
We trusted a document because it looked legitimate. We trusted an email because it appeared to come from a known sender. We trusted a photograph because it seemed to represent something that actually happened.
Artificial intelligence is fundamentally challenging those assumptions.
When convincing content can be generated at scale, trust can no longer depend solely on whether something looks real.
Increasingly, we need to ask:
This shifts the emphasis away from examining only the finished content and toward understanding the evidence surrounding its origin and history.
Importantly, provenance does not automatically tell us whether something is true.
It gives us evidence with which to make a better trust decision.
This is not just a theoretical concept.
The Coalition for Content Provenance and Authenticity, or C2PA, has developed a technical standard for establishing the provenance and authenticity of digital content. Content Credentials provide a model for storing and accessing cryptographically verifiable information about digital assets, including information related to their source and history.
The idea is fundamentally different from simply asking an algorithm to look at an image and determine whether AI created it.
Instead, it asks whether there is trustworthy evidence associated with the asset itself, including information about how it was created, how it changed and which actors or assets contributed to its history. C2PA uses digital signatures and content bindings to provide tamper-evident provenance information.
That is a very different trust model.
It moves us from:
“Does this look genuine?”
toward:
“What evidence do I have about where this came from?”
Regulation is beginning to move in a similar direction, too. The EU AI Act’s transparency requirements, together with the European Commission’s guidelines and Code of Practice for AI-generated content, reflect growing expectations around marking, labelling and transparency for synthetic content.
The direction is increasingly clear.
Trust needs to become verifiable.
There is another side to the provenance problem that may ultimately be even more important for cybersecurity leaders:
System provenance.
AI is no longer confined to chatbots and image generators.
Models, agents and AI services are increasingly becoming components inside software, connected products, engineering workflows and business processes.
That raises a much larger set of questions.
Which model is being used, and which version?
Where did it come from, and what software libraries and datasets does it depend on?
Which external services or APIs does it access?
Which tools can an AI agent invoke?
Which other agents or systems can it communicate with, and what permissions does it have?
What changed between versions?
What vulnerabilities exist in the components surrounding it?
And what happens when one part of that chain changes?
This is where the concept of provenance begins to converge with the evolution we have already seen in software supply chain security.
Cybersecurity professionals have been dealing with a version of this problem for years.
Software Bills of Materials emerged because organizations recognized that they could not adequately understand or secure a software product without knowing what was inside it.
An SBOM provides visibility into components and dependencies.
But the underlying principle is broader than inventory.
It is about traceability: what’s present, where it originated, which versions are in use, what depends on what, which vulnerabilities affect those components, and what is actually exposed in the context of the product.
The same concept is now expanding into artificial intelligence.
AI and Machine Learning Bills of Materials, often referred to as AI/ML BOMs or AIBOMs, are designed to provide greater transparency into the models, datasets, configurations and dependencies that make up AI-enabled systems.
CycloneDX, for example, supports AI/ML BOMs that can represent models, datasets, configurations and dependencies, including dataset provenance and training-related information.
This is an important evolution.
The BOM is becoming more than a software inventory.
It is increasingly becoming part of the evidence layer needed to understand complex digital systems.
Very few modern products operate in isolation.
Connected vehicles, medical devices, industrial systems, robotics and other software-defined products increasingly depend on ecosystems of software providers, open-source components, cloud services, APIs, AI models, datasets, suppliers and development tools.
AI makes these relationships even more dynamic.
An application may call an external model. That model may invoke a tool. An agent may access a database, generate code, interact with an API or communicate with another agent.
The final output may therefore represent the result of an entire chain of interactions that the person receiving it never sees.
That makes trust an ecosystem problem.
Organizations cannot establish confidence simply by examining the final output. They need visibility into the origin, lineage, dependencies, relationships and context that contributed to it.
The question becomes less:
“Is this real?”
And more:
“Do I understand enough about how this was produced to trust it?”
Historically, cybersecurity programs focused primarily on protecting organizational infrastructure, applications, identities and information.
That is no longer sufficient.
Cybersecurity leaders increasingly need to understand the provenance and dependencies of assets that originate outside their direct control.
Software. Open-source components. AI models. Datasets. APIs. Cloud services. Suppliers. AI agents.
And growing numbers of machine-to-machine and agent-to-agent interactions occurring at digital speed and scale, often without direct human involvement.
Understanding these relationships may become as important as protecting the traditional perimeter.
This also has major implications for governance and compliance.
When an organization needs to demonstrate why a cybersecurity decision was made, which components were affected, what changed, which risk was accepted or why a vulnerability was considered irrelevant, it needs more than a snapshot.
It needs evidence.
It needs context.
It needs traceability.
For manufacturers of software-defined products, provenance goes well beyond determining whether an image, document or video was generated by AI.
The same fundamental question applies to the products themselves:
Can you prove what is inside the product, where it came from, how it is connected, what has changed, and what risk those changes introduce?
This is where C2A Security fits.
C2A Security’s EVSec platform connects product architecture with Bills of Materials, vulnerability intelligence, threat modeling, risk assessment, compliance and security workflows in a shared product context. C2A describes EVSec as connecting SBOMs, threat models, risk and compliance in one product model.
Rather than treating an SBOM or other BOM as a static inventory, organizations can use that information as part of a living product security model.
That distinction becomes increasingly important as AI enters the product lifecycle.
Organizations need to understand not only traditional software dependencies, but increasingly the AI models, services and related components that are becoming part of their products and development environments.
EVSec BOM & Vulnerability Management supports SBOM, HBOM, AIBOM and CBOM management, continuous vulnerability monitoring, versioning and product-contextualized analysis. EVSec’s cyber model connects architecture and product context with threat and risk information, while AutoSynth AI & MCP Services adds AI-assisted automation and MCP capabilities across EVSec workflows.
The objective is not simply to accumulate more data.
It is to create the context required to understand what that data means:
Which component is affected?
Where is it used?
What depends on it?
Is the vulnerability actually relevant to this product?
Which risk, requirement or compliance obligation is connected to it?
That is the product cybersecurity version of provenance.
It creates a living chain of evidence connecting components, dependencies, changes, vulnerabilities, risks and compliance requirements throughout the product lifecycle.
And as AI becomes more deeply embedded in connected vehicles, medical devices, industrial systems, robotics and other cyber-physical products, that ability to establish context and traceability will become increasingly important.
AI will continue to make synthetic content more convincing.
AI agents will become more autonomous.
AI models will become more deeply integrated into products and development environments.
Software supply chains will become more complex, not less.
The answer cannot simply be to build ever-better technology for deciding whether something looks fake.
Detection matters.
Authentication matters.
Watermarking matters.
But they are only part of a much larger trust architecture.
Organizations will increasingly need the ability to establish transparency, provenance, traceability and context across the systems and ecosystems upon which they depend.
For digital content, that may mean understanding who created an asset, how it was generated and whether it was subsequently modified.
For an AI system, it may mean understanding its models, datasets, components, tools and dependencies.
For a software-defined product, it means understanding the software, hardware, AI, vulnerabilities, architecture, suppliers, risks and changes that collectively define the security of that product.
The principle is the same:
You cannot secure what you cannot understand.
And increasingly:
You cannot trust what you cannot trace.
In the age of AI, trust is no longer simply a content problem.
It is a provenance, context and ecosystem problem.
Whether we are talking about an AI-generated image, an autonomous agent, a software component or an entire connected product, the fundamental questions are becoming remarkably similar:
Where did it come from?
What contributed to it?
What happened to it along the way?
And can we prove it?
The organizations that can answer those questions will be the organizations best positioned to establish trust in the AI-driven world.
Building software-defined products and looking for the evidence, context and traceability behind your product security decisions? Talk to C2A Security about EVSec.
