This is the most common kind of agent workflow right now, creeping into our enterprise estates:
Agent → Slack → Jira → CI/CD → Cloud → Database
Each “hop” is authenticated. Each permission is “valid”. Each tool owner can show us their own little slice of control. And yet the system as a whole behaves like a single, autonomous super-user. That’s the invisible trust chain: a distributed privilege path that’s not been specifically mapped end-to-end, because no single team “owns” the whole chain.
Security architects are used to threat models with clear boundaries. This is how it should be. Agents, however, dissolve those boundaries. We’re not just deploying AI; we’re slowly and quietly minting autonomous machine identities, one innocent-looking approval click at a time, and letting them roam across SaaS and cloud with a bigger blast radius than most homosapiens.
The new generation of users, who refuse to accept cookies, is giving AI access to their desktops, files, bank accounts, and our business data.
Agents are Being Treated Like Insiders
Speaking to our clients and prospects, organizations are increasingly seeing AI as the top data security risk, largely because AI systems are being granted broad access to make them useful, with 61% of organizations identifying AI as their chief data security threat. [Thales]
Non-human identities (AI agents and service accounts) are seen as higher risk (52%) than human users (37%), and justifiably so, though 18% of organizations have granted AI services administrative permissions that are rarely audited. [Tenable].
Agents are now talking to agents, chaining permissions and further deepening what we can’t see, coordinating work, assigning responsibilities, and happily sharing context seamlessly across platforms, with A2A security rapidly becoming an SOC imperative.
“The work is mysterious. And important.”
- Mark S, The You You Are, Severance. [2022]
And that’s the new baseline: the problem isn’t that agents are “mysterious” or deliberately clandestine. It’s that they’re over-permissioned, under-audited, and highly connected by default.
Why The Invisible Trust Chain Happens
An invisible trust chain forms when four conditions line up:
- Agents are bolted onto existing tools, not designed into architecture.
Slack, Jira, GitHub, CI/CD, cloud consoles, data platforms. Each has its own permission model and audit surface. - Auth is fragmented across tokens, app consents, service principals, API keys, and roles.
Even strong per-hop controls don’t guarantee safe composition. - The agent can orchestrate actions faster than humans can notice.
We don’t get one risky API call; we get a sequence of “reasonable” calls that add up to compromise. - Nobody maps the chain, because nobody has the full view.
The app team owns Jira. The platform owns CI/CD. The Cloud team owns IAM. The data team owns the warehouse. Security owns… the incident.
The Weakest Link is Still Identity
A lot of agent deployments are still authenticated like it’s a side-project. Agent-to-agent auth commonly relies on API keys and generic tokens, while only 17.8% use Mutual TLS (mTLS, requiring both parties (client and server) to authenticate each other using digital certificates, ensuring secure, trusted, and encrypted communication. Even more telling: only 21.9% treat agents as independent, identity-bearing entities.
As such, we’re building automation that can take actions across production systems… and then authenticating it with shared secrets and “we’ll tidy it later” tokens. “Later” is doing a lot of heavy lifting there.
This matters because credential-based compromise is not a niche problem. Verizon’s 2025 DBIR analysis highlights compromised credentials as an initial access vector in 22% of breaches.
And the fuel for credential abuse is everywhere. GitGuardian reports 23.8 million secrets leaked on public GitHub in 2024 (a 25% YoY increase), and warns that 70% of leaked secrets remain active two years later.
If our invisible trust chain includes long-lived tokens or embedded secrets, we’ve essentially built a privileged integration layer on top of the most common breach primitive. Imagine what this is going to be like once we start inheriting these trust chains through the likes of mergers and acquisitions!
Tool Protocols Make Chains Longer, Not Safer
Interoperability is the accelerant. Protocols like Google’s Agent2Agent (A2A) are designed to let agents coordinate actions across enterprise apps, which is great for productivity and terrible for ungoverned trust edges.
MCP (Model Context Protocol) creates a structured integration layer between agents and external tools, turning ad hoc API calls into defined, interoperable connections. That’s incredibly useful, but it also creates new failure modes: tool poisoning, name collisions, rug-pull tool redefinitions, and multi-tool orchestration abuse.
The invisible trust chain becomes a web, and our old mental model (“who has access to the database?”) becomes impractical. The better question becomes: what chains of authenticated actions can be composed to reach the database, and what else can that chain touch on the way?
Constrain The Chain, Don’t Just Secure Links
Security architects don’t need a new philosophy here. We need to apply tried, tested, and existing identity discipline to agents:
- Prefer short-lived credentials and workload identities.
AWS explicitly recommends using roles with temporary credentials for workloads. Microsoft pushes automation away from user-based service accounts toward workload identities (managed identities/service principals). - Reduce standing privilege with JIT for high-risk roles.
Microsoft’s guidance recommends Privileged Identity Management and identity-first access to enable just-in-time role activation and remove persistent elevation. - Treat the agent as a first-class principal with scoping and policy boundaries.
OWASP’s LLM work is a useful umbrella for framing agent risks (prompt injection, supply chain, excessive agency, data exposure). However, none of that is enough if we only look at each system in isolation. The invisible trust chain is a graph problem. We need to see and govern privileges as a connected map across SaaS and cloud.
Visualize And Constrain Distributed Privilege Webs
This is where “platform thinking” wins: not because it’s shiny, but because the problem spans systems. The solution pattern is straightforward:
- Discover identities and entitlements across AWS/Azure/GCP and key SaaS (including non-human identities).
- Surface toxic combinations (the “agent can read tickets, change pipeline, assume cloud role, and pull from data store” path).
- Enforce least privilege and time-bound access so the chain can’t become permanent by stealth.
- Make agent access reviewable like any other privileged identity, with evidence we can hand to auditors to prove least privilege.
That’s how we turn an invisible trust chain into something we can actually secure: not a hunch or gut feeling (because that won’t cut it with auditors), not a spreadsheet, not “we’ll add it to the backlog”, but an architectural control that makes distributed privilege legible, constrainable, and governable.
The agent issue isn’t the future. Our invisible trust chain is already in production.
Trustle is identity governance for the agentic AI era. Check out our free trial, and get a grip on AI identity management in as little as 30 minutes.
