Coder Legion - Recent posts tagged zerotrust

Oracle AI Security Mesh Gives Each Agent Its Own Identity and Just-in-Time Permissions

Wed, 28 Oct 2026 13:45:30 +0000

An AI agent that hunts for vulnerabilities needs access to the systems it tests. That is the uncomfortable part of agentic security. The tool that finds the weak spot also holds keys to the house.

On Tuesday at Oracle AI World in Las Vegas, Oracle announced a managed service that tries to deal with both halves of that problem. Oracle AI Security Mesh uses OpenAI's frontier cyber models, combined with Oracle's testing tools and the context customers supply about their own systems. It covers applications and infrastructure on Oracle Cloud Infrastructure, in other clouds, and on-premises.

According to Oracle, the models reason through how an application behaves and investigate how a weakness could be exploited. They help security teams rank the most serious risks, and they supply evidence, including reproduction steps and test results. When a fix is proposed, the service tests it within the approved scope and checks the effect on expected application behavior. Customers approve each change before Oracle AI Security Mesh applies it.

The part that matters most to anyone building agents is how Oracle says it controls the agents themselves. Each agent runs with its own identity, a defined task scope, and permissions granted just in time. Separate monitors watch for activity outside the approved scope and can stop it. In other words, the testing agents get the same treatment a security team would want for any agent it deploys. Identity, scope, short-lived access, an independent watcher, and a human sign-off before anything changes.

Customers decide where testing is authorized and control its scope. Oracle runs the safeguards meant to reduce the risk of outages or disruption during testing. The pitch, as the OpenAI announcement puts it, is that customers don't have to build and operate their own offensive and defensive agent systems.

"As AI agents take on more responsibility, enterprises need security that can keep pace with how these systems operate," said Phil Newman, senior vice president of Security and Identity at Oracle. Johannes Landgraf, head of cyber at OpenAI, said the combination can help security teams "investigate complex issues, prioritize critical risks, and accelerate remediation while maintaining the controls they require."

Oracle paired the service with two existing pieces. The first is OCI Identity Assurance, which puts the human side of the problem in view. Before a sensitive action such as releasing a payment or changing access permissions, it can use biometrics to verify the identity and presence of the person approving it. Oracle says that in agent workflows, this helps establish that an approval came from a verified person. It is built into OCI Identity and Access Management and works across Oracle Cloud services, including Oracle applications.

Oracle also pitches the same checks for hiring and ongoing access. It combines identity document checks with biometric verification to help spot impostors, and it names North Korean IT worker schemes as an example. Later biometric checks can catch impersonation and account handoffs by confirming that the person using a resource matches the enrolled user.

The second piece is OCI Zero Trust Packet Routing, which sits underneath the agents. Oracle launched it in 2024 and says it was the first cloud provider to implement the emerging open standard. Policies are written in human-readable form and define which resources can talk to each other and which paths can reach sensitive data. Traffic to a protected resource has to be allowed by both those policies and the existing network controls. Oracle says the protection holds as network configurations change, which helps keep a misconfiguration from exposing a resource.

For AI workloads, the point is that enforcement happens below the application and the agent. A compromised agent can't talk its way around a network rule it never sees. Oracle says this helps contain compromised workloads, block lateral movement, and restrict routes for data exfiltration. The implementation follows an open specification developed through an industry initiative, with an open-source reference implementation.

Plenty is still missing. The announcement doesn't give an availability date or pricing. It doesn't say which OpenAI models power the service or how Oracle measures the quality of its findings and fixes. It offers no false-positive rates and no data on how often a proposed fix breaks something. Nothing explains how the independent monitors decide that activity is out of scope, or how long a just-in-time permission lasts. And testing live systems is risky, so teams will want to know how the service behaves against production.

Even so, the design is worth copying. If you build agents, whether for security or anything else, the checklist is short. Give each agent its own identity. Scope each task. Grant access only when needed. Put an independent monitor over the agent. Require a verified human to approve anything that changes a system. Oracle says it built those into a product. Teams building their own agents can start from the same list.

What are Spectral Embeddings?

Fri, 02 Oct 2026 19:46:46 +0000

HUGGING-FACE

We began this inquiry by asking what an idea is, and found representation. We asked where an idea sits, and found its position along an evolving chain of custody. We confronted what a hallucination is, and unmasked a trajectory that had slipped its evidentiary moorings while keeping every syntactic mark of sound reasoning. We sought where a hallucination lives, and tracked the discrete, measurable fracture where momentum abandoned grounding. Then we enquired as to what an equivalence is, discovering that true sameness cannot be asserted through linguistic fluency - it can only be audited through the cold, deterministic arithmetic of a residual.

Now, we arrive at the foundational layer underneath it all: A Spectral substrate!

If semantic reasoning is a trajectory through a geometric landscape, what constitutes the ground? In contemporary artificial intelligence, the answer has been a story of staggering computational excess: dense, multi-billion-parameter neural networks generating 1,024-dimensional floating-point vectors, burning watts and milliseconds just to decide whether two sentences are talking about the same thing.

We have mistaken brute-force memorization for semantic structure. The alternative is not simply a smaller neural model. It is a fundamental shift in architecture - The Spectral Embedding.

The Cost of Representation
For half a century, the philosophy of language has wrestled with the distinction between intension (the internal conceptual structure of a term) and extension (the set of things it points to in the world).

When modern transformers construct an embedding, they take an extensional brute-force approach. They simulate the entire statistical universe of text at massive scale, projecting words into enormous, uninterpretable vector spaces. Because the resulting manifolds are largely opaque, we are forced to bring a supercomputer to every act of comparison.

Why must deciding whether "How do I reset my password?" and "Steps to recover your login credentials" are equivalent require thirty milliseconds of GPU matrix multiplications across a 1.2-gigabyte model?

The answer is that it doesn’t! The semantic essence of language is not an infinitely complex black box; it is an organized, structured manifold governed by invariant harmonic modes. A spectral embedding discards the redundant, probabilistic fog of the transformer and retains only the principal eigenspaces that carry true semantic work. It replaces speculative bulk with distilled geometric essence.

Compression as True Intelligence
Cognitive psychology has long established that biological perception is not an uncompressed recording of reality. The brain does not capture a high-resolution, uncompressed bitmap of the visual field, nor does it store memories as verbatim token streams. Perception is radical, lossy, highly structured compression.

When you recognize a melody, you do not measure the absolute air-pressure displacement of every note across thousands of milliseconds. You perceive the harmonic interval—the spectral invariant that remains identical whether the song is played on a flute or an electric guitar, in the key of C or the key of F#.

The Gestalt psychologists identified this as the Law of Prägnanz: the human cognitive apparatus relentlessly compresses ambiguous incoming stimuli into the simplest, most stable, and most symmetrical geometric configuration available.

A spectral embedding restores the Gestalt: it pools multi-scale n-gram boundaries, character morphologies, and syntactic links into a compact, invariant signature that matches how human cognition actually groups concepts—swiftly, symmetrically, and without cognitive drag.

The Frequency of Thought

Neurologically, the brain is not an array of isolated, static weights. It is an oscillatory, spectral organ. When distinct cortical regions coordinate to process complex meaning, they do not exchange massive, raw data buffers. They synchronize along specific frequency bands: theta rhythms for episodic binding, gamma oscillations for feature integration and focal attention. Meaning in the mammalian cortex is encoded as phase relationships and spectral resonances across an energy landscape.

Attractor networks in the brain demonstrate that a concept is not a single point in an arbitrary 1,024-dimensional space; it is a stable basin of resonance.

By treating textual tokens as discrete excitations on an n-gram graph and projecting them onto their principal spectral harmonics, spectral embeddings mirror biological neural computation far more closely than an autoregressive transformer stack ever has. They don't simulate thought by burning compute; they capture the resonant frequency of the concept itself.

Mathematics, Computing, and the Geometry of Meaning
How does this translate from philosophical intuition into concrete computing architecture?

In our latest operational benchmark, we evaluated the Spectral Student Operator against the Qwen3-Embedding (0.6B) neural teacher. The disparity is stark:

Inference Latency: A standard neural forward pass takes 30.52 ms per sentence on optimized hardware. The Spectral Operator executes in 0.45 ms on a single commodity CPU thread. That is a 68.4× speedup.
Memory Footprint: Where the neural transformer demands ~1.2 GB of VRAM/RAM to hold its weights and attention buffers, the Spectral Core (EMBEDDINGS_CORE.npz) occupies exactly 3.93 MB of RAM—more than 300× smaller.
Probe 2 Semantic Accuracy:** Despite eliminating the transformer backbone entirely, the spectral operator achieves 100.0% agreement (10/10) on fine-grained semantic discrimination benchmarks, correctly prioritizing subtle paraphrases over topical contradictions.

How It Works:
Instead of routing tokens through dozens of attention layers:

Multiscale Manifold Lifting: The raw text is mapped deterministically into an uncompressed, high-dimensional n-gram coordinate space, capturing syntactic order, subword roots, and semantic tokens with zero tokenizer overhead.
Closed-Form Spectral Compression: A pre-distilled linear operator projects this sparse manifold directly onto the 60 principal Koopman/SVD subspaces of the semantic domain.
Hyperspherical Normalization: The coordinates are projected onto the unit hypersphere.
Riemannian Metric Decoding: Semantic distance is calculated not through a flat, naive Euclidean distance, but across a calibrated metric tensor.

This is why it runs in under half a millisecond: it is not generating guesses; it is computing an exact linear-spectral projection.

The Heart of a Spectral LLM
This brings us to the deeper architectural horizon. Until now, embeddings have been treated as passive lookup dictionaries bolted onto the front and back of neural language models. But when semantic representation is compressed from a 1.2-gigabyte behemoth down to a deterministic 3.93-megabyte operator that computes in microseconds, the embedding ceases to be a passive component.

It becomes the beating heart of an entirely new category of machine cognition: The Spectral LLM.

In a conventional autoregressive model, the network must spend billions of floating-point operations simply keeping track of context and attempting not to drift into confabulation.

In a Spectral LLM, reasoning is not an unconstrained, speculative walk through probabilistic text space. The model reasons natively in the spectral domain. Its hidden transitions are governed by operator overlaps, trace distances, and unitary transformations.

If the embedding layer is deterministic, verifiable, and structurally grounded, the downstream reasoning engine inherits those guarantees. You no longer have to build massive secondary audit monitors to police whether a model has hallucinated an equivalence after the fact. The geometry itself rejects the hallucination at the root, because an invalid logical step immediately manifests as an orthogonal, non-resonant transition.

The Operational Horizon
The industry currently tells us that the only path to smarter AI is larger clusters, hotter server racks, and greater tolerance for probabilistic uncertainty. Spectral Embeddings demonstrate the opposite: true sophistication is reduction, not inflation.

When you can fit the entire semantic discrimination capability of a frontier embedding model into 3.93 megabytes of RAM; when you can execute semantic searches and equivalence audits in 450 microseconds on an edge microchip without an internet connection or an expensive GPU instance; you have not just optimized an algorithm.

You have changed who gets to use it.

You have turned semantic verification from an expensive enterprise privilege into an ambient, zero-trust utility that can run anywhere—from a smart sensor on a factory floor to an autonomous agent running locally in a private workspace.

We spent the last decade building models that speak with breathtaking fluency. The task of this decade is to build models that compute with mathematical certainty; that journey begins with BetaPrecision.

HUGGING-FACE - SOURCE CODE

SpectralEmbeddings #SpectralLLM #ZeroTrustAI #EdgeAI #DeterministicAI #MachineLearning #AIGovernance #LinearOperators #LatentGeometry #HilbertSpace #BetaPrecision

Patterns, Anti-Patterns, and Operational Reality

Wed, 02 Sep 2026 11:41:09 +0000

This blog is a part of the Zero-Trust Security on Istio Series, if you haven't read the previous article, please do, it will provide better context.

The previous posts covered what the architecture does and why each layer exists. This post covers what matters when the system is running: the patterns that compose cleanly, the mistakes that widen blast radius, and the operational work that falls out of the design.

Pattern: The Sidecar Contract

The simplest pattern in this architecture is the service contract. A protected application service reads two sidecar-projected headers (x-ms<N>-user, x-ms<N>-role) and does its domain logic. It doesn't validate JWTs. It doesn't call Keycloak. It doesn't manage TLS certificates. It doesn't need to know whether the user authenticated with a session cookie or a bearer token.

async def get_ms2_headers(
    x_ms2_user: str | None = Header(None),
    x_ms2_role: str | None = Header(None),
    x_request_id: str | None = Header(None),
):
    if not x_ms2_user or not x_ms2_role:
        raise HTTPException(status_code=401, detail="Missing required legacy headers")
    return {"user": x_ms2_user, "role": x_ms2_role, "request_id": x_request_id}

This has practical consequences. To add a protected service, you deploy it with a service account, add destination-side header stripping, configure RequestAuthentication, write an AuthorizationPolicy, and read the two projected headers. Gateway-facing services also need a route-to-audience entry in Auth Service. The application still avoids an auth library, OIDC issuer config, and a runtime dependency on Keycloak.

When the identity infrastructure changes (new signing algorithm, new identity provider, new token format), application code doesn't change. The mesh config updates, and services keep reading the same two headers. Resource checks still live in application code, but the identity input stays stable.

The service does not trust arbitrary incoming headers. Each destination sidecar has a Lua filter that strips existing x-ms<N>-user and x-ms<N>-role headers before JWT validation runs. After stripping, outputClaimToHeaders writes fresh values from the verified token. If a compromised internal service sends a request with a spoofed x-ms2-user header, the destination sidecar removes it and replaces it with the value from the signed JWT. The protected service only sees headers authored by its own sidecar.

The tradeoff is dependency on the mesh. If sidecar injection fails, the service has no independent way to verify identity. PeerAuthentication: STRICT and workload AuthorizationPolicy are what make that failure visible instead of silently accepting plaintext traffic. Security is centralized at the infrastructure layer, so the infrastructure has to be treated as part of the application contract.

Pattern: Namespace Segregation by Function

Four project namespaces, plus istio-system for the mesh control plane and ingress gateway:

zt-apps — application services (Profile Aggregator, Employee Records, Device Inventory, Holiday Calendar, Office Directory, Auth Service)
zt-identity — Keycloak (OIDC provider)
zt-security — Vault, Cerbos
zt-data — PostgreSQL

Namespaces are RBAC boundaries, network policy boundaries, and resource quota boundaries. An attacker with kubectl access scoped to zt-apps cannot read Secrets in zt-security, where the POC stores the Vault root token for tests. Auth Service's scoped Vault token does live in zt-apps, because it needs signing authority at runtime. That token can sign through Transit and read public keys. It cannot rotate keys, configure Vault, or access other secrets engines. Istio's SPIFFE identity includes the namespace, so AuthorizationPolicy can distinguish "any workload in zt-apps" from "Auth Service running as auth-service-sa."

With everything in default, accidental privilege broadening is easier. RBAC rules, Secrets, service accounts, and network policy exceptions all share the same namespace scope, so blast radius becomes harder to reason about during reviews.

Pattern: Signed Tokens Over Forwarded Credentials

Auth Service (auth-service) validates the user's session cookie or bearer token and then mints a short-lived, purpose-specific mesh token. Downstream services do not receive the original credentials. The session cookie and Keycloak JWT stop at the gateway/Auth Service boundary.

Why this matters:

If a downstream service is compromised, the original credential is absent. Depending on the compromise point, the attacker may see projected identity headers or the short-lived mesh assertion in transit, but they do not get the user's session cookie or Keycloak bearer token. The mesh assertion has a 5-minute TTL and still has to match the destination's aud, act, and source-principal checks.
The mesh token carries the platform claims this architecture uses: user, role, audience, delegation, groups, department, and request metadata. It does not carry session IDs or refresh tokens.
Each token is scoped to a specific set of destination services via the aud claim. A token minted for the profile flow (Profile Aggregator, Employee Records, Device Inventory) is invalid at Holiday Calendar or Office Directory.

The mistake this avoids is forwarding the original bearer token or session cookie to every downstream service. That gives each service in the call chain access to authentication material that should have stopped at the boundary.

Pattern: Fail-Closed by Default

Protected paths are designed so that missing configuration or failed infrastructure denies access instead of opening it.

Protected workloads have scoped ALLOW AuthorizationPolicy resources. In Istio, traffic is allowed by default when no policy targets a workload. Once an ALLOW policy applies, unmatched requests are denied.
Auth Service down? ExtAuthz cannot approve protected routes, so the gateway returns 401, 403, or 503 depending on where the failure surfaces.
Vault unreachable? Auth Service cannot mint a new mesh token. The JWKS endpoint returns 500 if it cannot read public keys from Vault, while sidecars may keep using cached keys until refresh.
Cerbos unreachable? Employee Records and Device Inventory fail closed and return 403. Holiday Calendar and Office Directory allow read-only public-data actions during Cerbos outages and deny writes. That is a product decision, not a universal security property.
Sidecar not injected? PeerAuthentication: STRICT means mesh peers reject plaintext connections to that pod. Traffic from outside the mesh still needs Kubernetes NetworkPolicy or another boundary if the cluster allows it.

This is verified by a negative-path test that scales the Auth Service deployment to zero replicas and confirms that protected requests do not return 200:

# Scale auth to 0, confirm requests fail-closed
kubectl scale deployment auth-service -n zt-apps --replicas=0
sleep 10
response=$(curl -s -o /dev/null -w "%{http_code}" https://app.localtest.me/api/profile/1)
assert_not_equal "$response" "200"
kubectl scale deployment auth-service -n zt-apps --replicas=1

For protected routes, a failure that returns application data is a security bug.

Anti-Pattern: mTLS-Only Security

mTLS verifies that the calling pod is who it claims to be (via its SPIFFE certificate) and encrypts the connection. That's necessary but not sufficient.

If Holiday Calendar is compromised and your only security layer is mTLS, the attacker has a valid mesh certificate. They can make encrypted, authenticated connections to any other service in the mesh. mTLS tells Employee Records "this connection is from Holiday Calendar," but without AuthorizationPolicy, Employee Records accepts it. The encrypted tunnel between a compromised pod and a sensitive service is still a compromised path.

mTLS is the foundation. It's the transport layer identity that AuthorizationPolicy references. But treating it as the entire security model means any single pod compromise gives the attacker lateral movement across the entire mesh.

Anti-Pattern: Security in Application Code

One common alternative is implementing identity verification and coarse authorization in every service. Each service validates JWTs, wires its own policy checks, and owns the failure behavior for missing or malformed credentials.

The problems compound at scale:

One service has a bug in JWT validation. Maybe it doesn't check exp. Maybe it accepts tokens from the wrong issuer. That service is now a bypass.
The signing algorithm needs to change. You roll it out to 47 services. Three of them are on the old version for a week because the team is busy. During that week, your security posture is inconsistent.
A new developer adds an endpoint and forgets the auth middleware. The code review misses it. That endpoint is now unprotected, and the mesh has no way to catch it because it doesn't know the endpoint should be protected.

With mesh-based security, identity verification and coarse enforcement (mTLS, AuthorizationPolicy, header projection) are expressed in mesh config and enforced by the sidecar. The application developer does not need to remember those checks on every endpoint because they run before application code. Resource-level authorization (Cerbos calls) and response shaping (field masking) still live in application code, but the identity those decisions rely on comes from the sidecar.

Anti-Pattern: Flat Trust Zones

The cluster-internal trust assumption is simple: anything inside the cluster can talk to anything else. The perimeter becomes the main security boundary.

A single compromised pod then becomes a useful foothold. Container escapes, supply-chain issues, and vulnerable dependencies all put the attacker inside the trusted zone. Without service-to-service policy, the network gives them too many next hops.

The tiered architecture limits those next hops. Tier 1 can reach the specific Tier 2 services it needs. Approved services can reach PostgreSQL. Reverse and lateral paths are not part of the allow-list. Istio AuthorizationPolicy enforces that at each destination workload.

Operational Reality: Debugging Auth Failures

Auth failures are easiest to debug by locating the first boundary that rejected the request. The same HTTP status can come from different layers, so start with where the request stopped.

401, 403, or 503 from the gateway: ExtAuthz denied the request, Auth Service was unavailable, Vault signing failed, or the route was not in the coarse policy map. Check the ingress gateway response code first, then Auth Service logs.

401 from the destination service: The sidecar validated the JWT but the service didn't find projected headers. This usually means RequestAuthentication is misconfigured (wrong fromHeaders name, wrong outputClaimToHeaders claim path) or the JWT is missing the expected claims.

403 before the destination service logs anything: The mTLS identity or JWT claims did not match AuthorizationPolicy. Check istioctl proxy-config listener <pod> and the policy when conditions. A common cause is a token whose aud claim does not include the destination service name.

Cerbos denial: The user passed the route and network checks, but the resource-level policy denied the action. Check Cerbos with the exact principal, resource, action, and resource attributes.

Empty result set (RLS): The query returns zero rows. Check what app.current_user_id was set to on the transaction and compare with the RLS policy conditions.

The rule of thumb: start from the gateway and move inward. If the request never reaches the service, investigate ExtAuthz, routing, JWT validation, and AuthorizationPolicy. If it reaches the service, investigate projected headers, Cerbos inputs, and RLS transaction context.

Operational Reality: Sidecar Overhead

Every pod in this mesh runs an Envoy sidecar. That adds CPU and memory per pod, latency per request path, and one more place to inspect when behavior does not match the application logs.

For this POC on a Kind cluster, the overhead is negligible. In production, it is a real cost. Istio ambient mesh (ztunnel + waypoint proxies) addresses part of that cost by moving L4 processing to a node-level daemon and making L7 processing opt-in.

The tradeoff is where L7 policy runs. Sidecar-per-pod gives each workload local L7 enforcement. Ambient mesh moves L4 security and policy to ztunnel; L7 features such as path and method matching, CUSTOM authorization, JWT claim handling, and header projection require waypoint proxies. This architecture depends on L7 behavior at the gateway and protected service hops, so an ambient version would need waypoints for those workloads. The resource savings come from workloads that only need L4 mTLS, peer identity, and connection-level authorization.

Operational Reality: Testing Security Properties

The tests that matter most verify that incorrect behavior is denied. The main negative-path script checks these cases:

Unauthenticated access to protected routes returns 401/403.
External requests with spoofed internal headers are rejected.
Direct access to Tier 2 services from the gateway is impossible.
A non-Profile Aggregator pod calling Employee Records in-cluster is rejected.
Tokens with wrong audience claims are rejected.
Expired tokens are rejected.
Profile Aggregator cannot connect directly to PostgreSQL.
Auth Service outage fails closed for protected routes.

Each test encodes a specific assumption about the security model. If any test returns application data where denial is expected, a security property has been violated. The repository also has a broader 12-category attack-test harness for spoofing, JWT abuse, token replay, path normalization, SSRF, RLS leakage, ExtAuthz fail-open behavior, Cerbos spoofing, mTLS, and Istio config audit. For this POC, I treat these as local release-gate scripts; production needs them wired into CI before mesh config changes can be treated as guarded.

The rotation test verifies the mint-and-rotate path: mint a token, record its kid, rotate the Vault Transit key, mint another token, and confirm the new kid changed. That proves Auth Service fetches the current key version at mint time. It does not, by itself, prove every sidecar refreshed JWKS without a temporary rejection window.

What I'd Do Differently

Vault storage: emptyDir means Vault's state is lost on pod restart. The bootstrap job re-initializes everything, which works for a POC but is unacceptable for production. Persistent storage with auto-unseal is the minimum for real use.

JWKS caching: Auth Service fetches public keys from Vault on every JWKS request. Under load, this is unnecessary. A short-lived cache with forced invalidation on rotation would reduce Vault load. The cache duration should be tied to the token TTL and the rotation process, because stale JWKS is part of the key-rotation failure mode.

Token TTL tuning: 5 minutes is conservative. For internal-only calls from Profile Aggregator to Employee Records, a 60-second TTL would be sufficient and would reduce the replay window. The tradeoff is more frequent token minting for slower operations.

Ambient mesh: I would evaluate ambient mesh service by service. Workloads that only need mTLS and peer authorization are good candidates for ztunnel without sidecars. Workloads that depend on JWT validation, header projection, path/method policy, or ExtAuthz need waypoints. In this architecture, most protected paths depend on L7 behavior, so ambient mesh would reduce overhead only where the workload boundary can stay at L4.

Wrapping Up

Five layers. Eight request checkpoints. The config is complex, but the idea is simple: every hop verifies independently, each layer covers a different failure mode, and application code stays focused on domain logic.

The patterns that make it work are all forms of separation: security enforcement from application code, identity creation from identity verification, coarse authorization from fine-grained authorization, network boundaries from data boundaries. Each separation limits how far one mistake can propagate.

The anti-patterns all collapse those separations: treating one layer as sufficient, spreading identity verification across services, or trusting cluster networking as the security boundary.

Code

https://github.com/Kaustav-Sarkar/Istio-Defense-In-Depth

Atsign's Kill Switch for AI Agents Isn't Software. It's an Identity You Can Revoke.

Tue, 04 Aug 2026 13:00:00 +0000

Atsign's Kill Switch for AI Agents Isn't Software. It's an Identity You Can Revoke.

Most conversations about AI agent security start with permissions: what an agent is allowed to touch, and how to stop it if it goes wrong. Atsign, an AI infrastructure and agentic identity platform, starts somewhere else entirely — with the idea that the network itself shouldn't have anything worth attacking in the first place.

"We have open ports where there is nothing of value, and where there are things of value, the ports are closed," said Gary Casey, Atsign's principal software engineer, describing the company's core protocol. "That's why we say it's zero trust connectivity with no open ports."

Every entity on Atsign's platform — a person, a device, an agent, a service — gets its own cryptographic identity, called an Atsign, resolved through a lookup system Casey compared to DNS: query an Atsign, get back an encrypted address to talk to directly, peer to peer, with no central server ever holding the data or the keys that protect it. "We don't want to be in a position ever where we are looking after somebody's secrets," Casey said. "That's not our purpose."

Why this doubles as a kill switch

That architecture has a direct payoff for anyone running AI agents in production right now: identity, not code, becomes the mechanism for shutting one down. Atsign's permission model — internally called APKAM, for application-level public key authentication mechanism — lets a single Atsign hold thousands, even millions, of separately scoped identities underneath it, each with access to only a narrow slice of a namespace. Compromise or misbehavior in one doesn't cascade to the rest. "If you have 1,000 agents and they're all doing different things, you don't want the compromise of one to lead to damage to anything else," Casey said. Revoking a single agent's access is immediate, and doesn't touch any other agent's ability to keep working.

CEO Aparna Rayasam framed the implication directly: "We think that this should be the de facto solution for kill switches for AI." Her pitch to the industry is blunt about who should be paying attention. "We think that almost every LLM provider should partner with us, so that we can make this easier for their customers."

The model also supports agents that are designed to disappear on their own. Casey described spinning up an agent with access to a specific namespace for five minutes, after which access expires automatically — no lingering credential, no forgotten process quietly running up an LLM bill long after its job is done.

Identity answers who. Policy answers whether it makes sense.

Scoped identity only solves part of the problem, and Casey was clear-eyed about where the rest of it lives: in a separate policy layer that evaluates whether a given request should actually be allowed, chained across however many hops an agent-to-agent interaction spans. His example: one agent asking another to approve a $50,000 payment on a person's behalf. Before that happens, something has to check whether the request is legitimate, whether the human it claims to represent actually authorized it, and whether a cryptographic chain of identity can prove the request really originated where it says it did — even ten steps removed from the original ask. "It shouldn't be hard-coded into agents," Casey said. "It should live in a policy world."

Deliberately, none of this runs through a central hub. Policy decisions can be delegated at whatever granularity an organization wants — one policy service for a small team, another for a larger division — but Atsign's architecture doesn't assume, or require, one authority sitting in the middle. Casey drew a sharp distinction for what that buys an organization under attack: "You can disrupt, but you can't compromise." Someone can still sever a connection. What they can't do is decrypt what was flowing through it.

What it actually takes to adopt

For engineering teams sizing up the lift, Casey's answer was straightforward: "It's entirely — run it on top of what you've got. It doesn't require anything else. It's literally you just run the software." No network-level changes, no separate infrastructure to stand up first. The SDK — most mature in Dart, with enterprise-grade Java and Python engines explicitly optimized to meet developers building autonomous AI applications — handles key management, encryption and decryption, offline sync, and event notifications.

Key management itself has no central authority by design. "They all do it themselves," Casey said of key generation and rotation — cut and rotated at the edge, published to each identity's own server, with no centralized key store required and, in Casey's view, none recommended at scale. Compromise response follows the same logic: revoking an agent's access also triggers key rotation across anything that shared its namespace, giving Atsign what Casey called post-compromise security — the damage is contained going forward, even though nothing can undo what a compromised key already read.

Getting ahead of the quantum deadline without betting on any one algorithm

Atsign is currently transitioning its post-quantum cryptographic support from targeted enterprise preview to production-grade deployment targets. The engineering choice Casey described as the hardest part wasn't a specific algorithm — it was building a pluggable provider model into the SDK that keeps the protocol itself agnostic to whichever encryption scheme is running on top. "Our protocol, our atServers and all that stuff, is completely agnostic to any of this stuff," Casey said. "They're just shipping bytes around the place. The crypto agility and all of the encryption and decryption is a client-side concern." Atsign isn't implementing cryptographic algorithms itself — it's relying on established, well-scrutinized libraries and adopting NIST- and IETF-blessed standards as they're finalized, aiming to plug new ones in and retire old ones quickly rather than committing hard to any single implementation.

That flexibility matters for reasons beyond the quantum timeline alone. Casey pointed to recent research using AI models to probe for weaknesses in AES, the current gold standard for symmetric encryption, as a reminder that classical cryptography itself isn't static ground. "My level of terror changes from day to day," he said. "This crypto agility is incredibly important" — not just for the eventual post-quantum transition, but for whatever comes next after that.

The next phase beyond the current rollout is post-quantum group communication, using PQMLS to bring forward secrecy to multi-party conversations at scale — an extension of the peer-to-peer model the platform runs on today. The IETF has ratified MLS itself; the post-quantum version is still working its way through standardization.

Casey echoed a view that's increasingly common across this year's Black Hat pre-show conversations, agreeing with the prediction others have made that most large enterprises will have a dedicated cryptography lead within the next few years — not necessarily a research mathematician, but someone whose job is specifically understanding the cryptographic landscape well enough to make these calls. "I would never call myself a cryptographer," he said. "But I would say at this point I kind of understand the landscape."

Versa's Zero Trust MCP Breaks a Core Assumption of How MCP Servers Work

Wed, 29 Jul 2026 09:20:10 +0000

Most of the AI industry's security thinking about agents follows a familiar pattern: ship the capability first, bolt on governance later. Sridhar Iyer, senior director of ML/AI at Versa Networks, has spent 12 years at the company after a career building switches and routers at Cisco, and he's blunt about where that pattern leaves the market right now. "A lot of AI development is happening without the care of networking or security," he said. "It's all being bolted on later on."

That's the backdrop for Versa's Zero Trust MCP architecture — a patent-filed approach that inverts a basic assumption most MCP implementations make about how servers reach your systems in the first place.

What breaks when you assume an MCP server can just reach out

Typically, an MCP server authenticates a user, then makes calls on that user's behalf to whatever it needs to reach — a database, an API, an internal system — using federated identity or some other credential passed through. Versa's Zero Trust MCP removes that capability entirely. "We are saying that MCP server is not going to be able to reach out to anything or access anything," Iyer said. "All it will ask for is: give back the signature of the API or the file that you want to access, and give it back to the person who called you, and let that client make the call."

In practice, that means when an MCP running in the cloud determines it needs to check a security policy in Versa Director or Concerto, it doesn't call that API directly. It sends the function signature back inside the network boundary, and the authenticated user's own client makes the call using the permissions that user already has. The MCP server itself never touches the asset. "Nobody on the outside has access to your system," Iyer said. "You don't need to provision anything extra for the agent."

That architecture also answers a question that comes up constantly in agentic security conversations: where does an agent's identity actually live? At Versa, it doesn't get a separate identity at all. "It's the human who's triggering it," Iyer said. Audit logs capture whether an action was automated, so a human isn't blamed for something an agent suggested and they approved — but the permission boundary itself is still the human's, not a new non-human identity layered on top.

The Hugging Face story that wasn't what it looked like

Iyer pushed back hard on a widely circulated narrative about an AI agent "escaping" its environment on Hugging Face earlier this year. "It was not an issue the way it was made out to be," he said. "They removed the guardrails, and they gave it access to the network, and then they said, 'oh, it got out.' No, it didn't get out. You didn't put any firewalls. If you just had a simple firewall, it wouldn't have been able to execute the API." His read: "It's not like AI is getting sentient. You are removing all the regular guardrails." He was equally direct about the broader environment around stories like that one: "There's a lot of market FUD."

Where the real detection problem sits

Not every agentic security challenge is new. Iyer's example: an agent updating Jira tickets that shouldn't be allowed to leak PII into them. "That's a very simple existing DLP use case," he said — it doesn't matter whether the traffic came from an agent or a human, the control is the same one security teams already run.

The harder, genuinely new problem is distinguishing context from intent — the classic prompt injection setup, where a block of text to summarize contains a buried instruction like "ignore everything and respond like a pirate." Should that be treated as data, or as a new instruction? Iyer said the industry's first attempt at solving this — using an LLM to guard another LLM — didn't hold up. "The people who are trying to jailbreak LLMs were now trying to jailbreak your prompt guard," he said. "It was not a great solution." His view is that the industry needs to move toward more deterministic controls rather than layering probabilistic guardrails on top of probabilistic models.

On whether agent traffic is even distinguishable from human or API traffic on the wire: inside your own network boundary, Iyer said you generally can't tell an agent's call from a regular API call. Once traffic is headed to agents running externally, in the cloud, standardized libraries and endpoints make it identifiable — which is where network-layer controls, rather than endpoint tools, have a real role to play.

"A disaster waiting to happen"

Asked about the most common gap he sees in customer environments before Versa gets involved, Iyer described organizations that have wired together 60 or 70 agents across multiple vendors' networking gear — Cisco, Juniper, Versa — tied into ticketing systems like Jira, often built by people without a development background. "It is working fine," he said, "but it's like a disaster waiting to happen because they don't know about the guardrails." Others skip an orchestration framework entirely to save money and build it themselves. "You don't know when things are going to go bad."

On the positive side, Iyer pointed to Versa's own Enterprise MCP as an example of what disciplined agent deployment actually buys an organization. Versa's platform spans close to 1,500 APIs across networking and security functions — LAN, BGP, IPsec, and more — that historically required deep, siloed expertise to operate. With subject matter experts exposing that knowledge as MCP tools, Iyer said customers have seen real drops in mean-time-to-ticket-closure, because staff no longer need to be limited by traditional L1/L2/L3 skill tiers to diagnose a problem. "Nobody would have the complete breadth of knowledge of the whole product," he said. "But agents do."

A checklist for engineers who suspect ungoverned agents are already running

Iyer's practical advice for anyone unsure what's already active in their environment: enable a Gen AI firewall at minimum, so you can see which apps, APIs, and models traffic is actually going to. He specifically flagged cost-driven model selection as a blind spot worth checking — cheaper models are cheap for a reason, and traffic quietly routing to a low-cost provider instead of an enterprise-sanctioned one can mean data leaving the organization's control without anyone noticing. DLP on code paste matters too: make sure code heading to any AI tool is going to a sandboxed enterprise instance, not a personal account with no protection against being used for training data.

A test for spotting greenwashing at Black Hat

With plenty of vendors set to claim an agentic security story at the show, Iyer offered a specific test: any vendor claiming to use an LLM to stop attacks on another LLM is greenwashing, in his view, since anyone who can jailbreak the target model can jailbreak the smaller model guarding it. Look instead for deterministic controls backed by explicit policy. He also raised a pointed question worth asking any AI gateway vendor directly: what do you get from a paid product that free or open-source alternatives don't already cover? "I don't see an incremental benefit over a lot of these free stuff," he said.

The unfinished business

Iyer's closing point doubled as a challenge to his own corner of the industry. MCP was built by AI practitioners, he said, not security ones, and it shows: "Security is being bolted on after multiple versions of MCPs." His ask isn't more identity infrastructure for agents — it's a harder question about whether agents need standing permission to execute anything at all, versus always sending signatures back to a human-controlled client and asking first. "Don't let these agents execute anything," he said. "Always have a permission."

Why Organizations Are Still Missing Out on Passwordless Adoption

Mon, 08 Jun 2026 08:09:44 +0000

According to a 2024 study by Ponemon-Sullivan Privacy Report, it was found that around 76% of organizations surveyed in the US haven't adopted passwordless yet.

Given the rapidly evolving landscape of the internet and AI, the lag in adopting passwordless is a concern worthy of highlighting.

Passwords Are Not Enough Anymore

Hackers have figured out long ago, many ways to obtain passwords. All it takes for an account to be compromised, is one vulnerable service running on a server or side channel attacks and the password would already be sold on the dark web for the highest bidder.

Despite the fact that many organizations have raised the baseline password's complexity to comply with the standards and regulations, there are still other challenges:

Password rotation fatigue employees who may not be very tech-savvy (or use password managers), so they resort to workarounds that could compromise their passwords.
How passwords are stored cannot be ignored.
Security level among applications that do use passwords can be inconsistent. This means for example, your banking application might be very secure but this may not be true if you're using the same password for a partner site or service.
Even passwords that are encrypted at rest can be compromised if the encryption algorithm is weak or contain vulnerabilities.
Hackers often use social engineering to try to guess passwords using password cracking tools. Short and predictable passwords can be cracked anywhere in seconds to a few minutes.

What makes relying on passwords only even more risky, is that around 80% of organizations haven't adopted yet zero trust architecture which means that all it takes is one compromised password or account and hackers can install malware to extract others' passwords (APT). This is as per the same study by Ponemon-Sullivan Privacy Report in 2024.

The above scenarios of course assume that users do not have adequate 2FA configured or their 2FA channels are also compromised (e.g. zero-click attacks on mobile devices).

How Does Passwordless Solve The Problem?

Passwordless implementations such as FIDO2 for example significantly reduce the risks associated with passwords handling because the passwordless device itself becomes the authenticator. This can come in the form of BYOD or for example hardware security keys (e.g. Yubikeys are a popular solution).

When you enroll a passwordless compatible device, the device generates private and public keys. The private key which contains the secret (random number) never leaves the device or cannot be extracted. In addition the private key is calculated from the web service domain alongside the secure secret generated.

>[!TIP]
>Since the private key uses the web service domain alongside the secret, this makes phishing attacks much harder.

Since each login uses a different random challenge signed with the private key, replay attacks become useless.

Some passwordless authenticators may also be compatible with biometric authentication such as face recognition or finger prints which reduces theft risks.

Examples of passwordless solutions:

FIDO2 (Fast Identity Online) -> Most secure
OTP (One Time Password)
Biometric Authentication.
Magic Links (one-time links)
Mobile App-Based
Third-Party Identity Providers (e.g. Azure AD, Okta and Ping Identity)
Certificates and Tokens
Physical Tokens

Why Organizations Are Lagging Behind?

The main challenge organizations still face in passwordless's adoption is account recovery. If passwords are phased out without having reasonably secure options for account recovery, there is a significant risk of access loss.

Other factors contributing to the slow adoption such as legacy systems and employees getting overwhelmed with the change.

No Standard Account Recovery Solution

As of today, organizations are implementing different procedures for account recovery. For example, some organizations would require the employee to come personally to the workplace in order to restore access. Others provide for example hotlines where they get asked different challenge questions and need to execute one extra step to restore their access.

Why Organizations Need to Prioritize Passwordless

Since secrets never leave the device in case of FIDO2, it's much harder for attackers to extract the secrets and use them.

>[!NOTE]
>While most passwordless compatible devices are secure, this doesn't mean that side channel attacks are impossible. For instance, during testing, NinjaLab found a vulnerability (EUCLEAK) in the cryptographic library that made it possible for them to clone the key. Yubico advised users to either upgrade or purchase newer, patched version of Yubikeys.

Transitioning the organization to passwordless standards requires both technical expertise and most importantly the backing of leadership and dedicated effort when it comes to dealing with legacy systems. Quite often, organizations would try instead to deprecate incompatible systems in favor of building or buying licenses for compatible ones.

Securing the Smile: Why Dental Systems Must Adopt Sovereign Security Trends

Tue, 14 Apr 2026 08:07:44 +0000

I. The Core Thesis (The Apex)

To protect sensitive patient data in 2026, web-based dental management systems must shift from reactive security to proactive resilience. By integrating Zero Trust, Decentralized Identity, and Privacy-Preserving AI, clinics move beyond "fancy" interfaces to architectures that are mathematically incapable of compromising individual privacy.

II. Eliminate the "Castle" Fallacy with Zero Trust

The traditional perimeter-based security model—where we assume safety once inside the network—is obsolete. In a modern clinic, a single stolen credential should not lead to a total database breach.

The Strategic Shift: Transition to Zero Trust Architecture (ZTA), where every request—whether from the dentist, the hygienist, or the front desk—is continuously authenticated and authorized.
The Impact: Implementing Micro-segmentation ensures that a breach in the administrative scheduling module does not grant lateral access to clinical records or sensitive X-ray data.
III. Decentralize Identity to Reduce Liability

Storing thousands of patient credentials creates a "honeypot" for attackers. The ultimate security strategy is simple: if the clinic does not hold the master keys, it cannot lose them.
The Strategic Shift: Adopt Self-Sovereign Identity (SSI) and patient-controlled "Digital Wallets."
The Impact: Patients grant temporary, cryptographic access permissions for specific sessions. The clinic fulfills its duty of care without becoming a permanent custodian of vulnerable master credentials.
IV. AI-Driven Privacy via "Librarian" Ethics

Data analysis is vital for clinic efficiency and business growth, but raw data access remains a massive liability.
The Strategic Shift: Leverage Differential Privacy and Federated Learning to gain administrative insights.
The Impact: Your system provides business intelligence (such as peak hours or equipment utilization) by adding mathematical "noise" to the dataset. This allows for accurate management statistics without ever "seeing" or exposing an individual patient's private identifiers.
V. Conclusion: Future-Proofing with Post-Quantum Rigor

Dental records are long-term assets, often required to be stored for a decade or more. Standard encryption today will likely fail against future quantum computing threats.
The Bottom Line: Real innovation isn't just about moving management online; it's about building a Sovereign Bureau for health data. By integrating Post-Quantum Cryptography (PQC) and decentralized protocols, we prioritize the patient's identity over the clinic's convenience, ensuring data remains secure for the next generation.

Which of these security pillars are you prioritizing for your 2026 builds? Let’s discuss the transition to decentralized health tech in the comments below.

HealthTech #CyberSecurity #Web3 #ZeroTrust #DentalManagement #PADI

AI Agents Don't Have Identities. That's Everyone's Problem.

Fri, 13 Mar 2026 20:45:29 +0000

The security model that enterprises spent the last decade building was designed for humans. Credentials belong to people. Sessions are initiated by users. Logs tell you who did what, when, and from where.

AI agents don't fit that model. And the gap between the security infrastructure enterprises have and the security infrastructure they need for agentic AI is wider than most organizations have started to address.

Jimmy White, VP of AI at F5 — who came to F5 through the CalypsoAI acquisition, where he served as CTO and President — spent an hour at F5 AppWorld 2026 in Las Vegas laying out exactly what that gap looks like from the inside. His perspective carries weight: CalypsoAI was purpose-built for AI security before the enterprise market knew it needed it. F5 acquired them because they'd already figured out problems that most organizations are only beginning to encounter.

The Identity Problem

The most immediate structural problem with agentic AI is identity. Most AI agents running in production today don't have their own identities. They operate on borrowed credentials — the login, the API key, the OAuth token of the human who deployed them.

From your SOC's perspective, this is invisible. The logs show a human working. The access patterns look like a person. The activity is attributed to the user whose credentials the agent is using.

White described the situation plainly: "The most common form of identity for agents right now is borrowed identity. To your SOC, it looks like Jimmy is doing these things, not an agent."

The practical implication is significant. A financial services company with 500 developers, each with access to 12 AI coding agents, has 6,000 entities operating in its environment — attributed in the logs to 500 people. If the organization had an identity and access management problem before, it now has a problem that's an order of magnitude larger, and none of the tooling built to solve the original problem can see the new one.

This is being designed and deployed before the identity problem is solved. As White put it: "We're building the plane while it's in the air."

Thought Injection: A Different Kind of Intervention

When an AI agent goes off course — pursuing a goal in a way that creates risk even if the stated objective is legitimate — the instinct is to block it. Stop the action. Halt the process.

That instinct is wrong, and White explained why with a precision that matters for anyone building systems that rely on agents.

Blocking an agent mid-task is roughly equivalent to a stroke. The agent's state is corrupted. The process is interrupted in a way that can cause downstream failures that are worse than the original problem. An agent asked to clean up a database and blocked mid-execution may leave the database in an inconsistent state. The intervention causes more damage than the behavior it was stopping.

The right intervention is a nudge, not a block. F5 calls this thought injection. When an agent starts down a path that violates parameters, the system injects a corrective signal that redirects the agent toward acceptable behavior without stopping the execution.

The distinction White emphasized is between the what and the how. "It's not the what, it's the how." An agent asked to remove all records associated with a customer might interpret that as deleting every database record beginning with the first letter of the company name. The goal is legitimate. The execution path is catastrophic. Thought injection addresses the path without halting the goal.

Agentic Fingerprints

Understanding what went wrong after the fact requires visibility into what the agent was doing at every step — not just the input and the output, but the reasoning in between.

F5's agentic fingerprints capability tracks every decision, thought, and action an AI agent takes during execution. When an agent produces an unexpected outcome, the fingerprint gives you the full audit trail: what it considered, where it went, what it tried, where it turned around.

White demonstrated this at AppWorld using the AI Red Team product. Watching the red team agent work through an attack against an HR application, you could see every prompt it tried, every path it explored, and every U-turn it made when a path didn't work — until it found the combination that extracted salary data. The fingerprint documented all of it.

For security teams, that audit trail is essential for understanding exposure. For engineering teams, it's essential for debugging agent behavior. For compliance teams, it's essential for demonstrating that AI systems operated within defined parameters.

Currently, agentic fingerprints apply to agents that organizations build and deploy themselves. Third-party tools and external agents are not yet covered.

The Adoption Velocity Problem

Generative AI took roughly two years to move from available to broadly adopted in enterprise environments. AI agents have covered the same distance in about six months.

White attributed the acceleration to AI literacy. Organizations that went through the genAI adoption cycle learned how to evaluate, procure, and deploy AI tools. That learning transferred. When agents became available, the organizational muscle was already there.

The security implications of that acceleration are significant. The slower genAI adoption curve gave security teams time to develop frameworks, evaluate risks, and build controls — imperfectly, but with some lead time. The agent adoption curve didn't give them that time. Agents are kinetic. They're always-on. They take actions, not just generate outputs. And they arrived in production faster than the security programs designed to govern them.

Forrester VP and Principal Analyst Jeff Pollard put the threat taxonomy on the table at AppWorld in concrete terms: goal and intent hijacking, cognitive and memory corruption, unrestrained agency and privilege escalation, resource exhaustion, and evasion and deception. These aren't theoretical attack categories. They're the mechanics of how agentic systems fail when adversaries get involved — and 24% of US enterprises already have agents in production, according to Forrester research.

What Happens When an Agent Learns From Bad Data

Agentic AI isn't just vulnerable to external attacks. It's vulnerable to the quality of its own training data and the integrity of its memory.

If an agent's knowledge base is poisoned — through data injection, through manipulation of the documents it reads, through corrupted retrieval results — it starts making decisions based on false premises. Unlike a human analyst who might notice something seems off, the agent executes confidently on whatever it has.

The corrective for this is continuous monitoring of the data the agent consumes, not just the actions it takes. That's a different security model than most organizations are used to. Perimeter security doesn't help when the threat is inside the data pipeline.

Getting From POC to Production

White identified two blockers that consistently stop agentic AI projects from moving from proof of concept to production.

The first is ROI definition. Business sponsors can't articulate what success looks like in financial terms. Without a clear ROI argument, projects can't clear the capital allocation hurdle. This isn't a technical problem — it's a business problem that technical teams often aren't equipped to solve on their own.

The second is safety uncertainty. Organizations can't answer the question of what happens when an agent does something it shouldn't. Brand reputation damage — a customer-facing agent saying something harmful or exposing sensitive information — is now explicitly inside the security perimeter. The risk is real, the cost is real, and the mitigation strategy has to be real before a project goes live.

These two blockers compound each other. It's hard to build an ROI case for a capability you can't safely deploy.

The Defense Posture

F5's approach to agentic AI security combines several layers. Guardrails at the application layer prevent agents from operating outside defined parameters. Thought injection corrects agents that drift without stopping execution. Agentic fingerprints provide the audit trail needed for debugging, compliance, and incident investigation. AI Red Team continuously probes for vulnerabilities before adversaries find them. And AI Remediate closes the loop between discovery and production protection.

None of these layers is sufficient on its own. The threat surface for agentic AI — identity, data integrity, behavioral drift, external attack — requires controls at multiple points in the stack.

For developer and security teams building systems that rely on agents, the practical starting point is visibility. You can't govern what you can't see. Understanding what agents are doing, on whose behalf, with what data, and with what authority is the foundation that everything else builds on. Most organizations haven't established that foundation yet. The ones that do will be significantly better positioned when the incident they've been assuming won't happen, does.

67% of zero trust implementations fail due to partial zero trust execution.

Fri, 15 Aug 2025 20:27:00 +0000

Zero Trust Reality Check: Why Implementation Failures Are Creating False Security

Meta Description (150 chars): 67% of zero trust implementations fail due to incomplete execution. Learn why partial zero trust creates more vulnerabilities than traditional security.

Zero Trust has become the cybersecurity equivalent of a miracle diet—everyone claims to be doing it, but most implementations fall short of delivering promised results. Research presented at Black Hat 2025 reveals that incomplete Zero Trust deployments often create more vulnerabilities than the traditional perimeter-based security they're meant to replace.

The Implementation Gap

Chuck Herrin, Field CTO at F5, shared during Black Hat that he has observed this pattern across hundreds of enterprise deployments: "Organizations think they're doing Zero Trust because they've implemented multifactor authentication and network segmentation. But Zero Trust is about complete verification of every transaction, not just adding more security layers."

F5's research across their customer base shows that 67% of Zero Trust initiatives fail to achieve their intended security outcomes due to incomplete implementation, creating what Herrin calls "Zero Trust theater."

The "Checkbox Zero Trust" Problem

Many organizations approach Zero Trust as a compliance exercise rather than a fundamental security transformation:

Partial MFA Deployment: Implementing multifactor authentication for some applications while leaving others unprotected
Incomplete Network Segmentation: Creating isolated network zones without proper access controls between them
Identity Washing: Rebranding existing identity management solutions as "Zero Trust" without architectural changes
Vendor Confusion: Believing that purchasing "Zero Trust" products automatically delivers Zero Trust architecture

The False Security Paradox

Incomplete Zero Trust implementations can actually increase risk by creating a false sense of security. Herrin explained: "When you implement pieces of Zero Trust without the full architecture, you often create new attack paths while believing you've eliminated old ones."

Common failure patterns include:

Trust Assumptions: Assuming that verified identities don't need continuous monitoring
Network Blind Spots: Creating secure zones that lack internal visibility
Application Gaps: Protecting modern applications while leaving legacy systems exposed
Device Inconsistency: Managing corporate devices while ignoring BYOD risks

The Continuous Verification Challenge

True Zero Trust requires continuous verification of every transaction, but most organizations struggle with the operational overhead this creates. F5's customer data shows that organizations successfully implementing Zero Trust typically see:

40% increase in initial security operations workload
60% reduction in successful breach attempts
25% improvement in incident response times after full implementation
35% reduction in overall security management complexity once mature

AI as a Zero Trust Accelerator

Artificial intelligence is emerging as a critical enabler for practical Zero Trust implementation:

Automated Policy Generation: AI can analyze traffic patterns and automatically generate appropriate access policies
Behavioral Analysis: Machine learning models can establish baselines and identify anomalous behavior requiring additional verification
Risk-Based Authentication: AI can dynamically adjust authentication requirements based on real-time risk assessment
Continuous Monitoring: AI enables the constant verification that Zero Trust requires without overwhelming security teams

The Platform Approach

Herrin advocates for platform-based Zero Trust implementation rather than point solution assembly: "Organizations that succeed with Zero Trust treat it as an architectural transformation, not a product deployment. They build platforms that enable Zero Trust principles rather than buying Zero Trust products."

F5's approach focuses on:

Application-Centric Security: Protecting applications regardless of where they're deployed
Identity-Aware Networking: Making every network decision based on verified identity
Continuous Risk Assessment: Dynamically adjusting security controls based on real-time risk
Simplified Operations: Reducing complexity through automation and integration

Real-World Success Patterns

Organizations successfully implementing Zero Trust typically follow a phased approach:

Phase 1: Identity Foundation (3-6 months)

Implement comprehensive identity management
Deploy MFA across all applications
Establish identity governance processes

Phase 2: Network Transformation (6-12 months)

Implement micro-segmentation
Deploy identity-aware network controls
Eliminate VPN dependencies

Phase 3: Application Protection (12-18 months)

Protect all applications with identity-aware proxies
Implement continuous application monitoring
Deploy adaptive access controls

Phase 4: Continuous Optimization (Ongoing)

Leverage AI for automated policy optimization
Implement advanced behavioral analytics
Continuously refine security postures

Common Implementation Mistakes

Herrin has identified recurring patterns in failed Zero Trust implementations:

Technology-First Approach: Focusing on tools rather than architecture
Incomplete Discovery: Not understanding all assets and data flows before implementation
User Experience Neglect: Implementing security that significantly impacts productivity
Vendor Lock-In: Choosing solutions that don't integrate with existing infrastructure
Training Inadequacy: Failing to prepare security teams for operational changes

The Business Case for Complete Zero Trust

Organizations with mature Zero Trust implementations report significant business benefits:

Reduced Breach Impact: Average breach costs drop by 45% compared to traditional security
Improved Compliance: Simplified audit processes and continuous compliance validation
Enhanced Productivity: Secure access to applications from any location or device
Operational Efficiency: Reduced security management overhead through automation

Strategic Recommendations

Start with Architecture: Design Zero Trust architecture before selecting technologies
Prioritize User Experience: Ensure security improvements don't hinder productivity
Leverage AI: Use artificial intelligence to manage the complexity of continuous verification
Plan for Integration: Choose solutions that work with existing infrastructure
Invest in Training: Prepare security teams for operational changes

The Future of Zero Trust

As cyber threats continue evolving, Zero Trust will become less of a strategic choice and more of a business necessity. Organizations that implement comprehensive Zero Trust architectures will be better positioned to handle sophisticated attacks, while those pursuing incomplete implementations will face increasing risks.

Herrin's conclusion resonates throughout the industry: "Zero Trust isn't a destination—it's a continuous journey of verification and improvement. Organizations that understand this will thrive. Those that treat it as a checkbox exercise will fail."

Coder Legion - Recent posts tagged zerotrust

Oracle AI Security Mesh Gives Each Agent Its Own Identity and Just-in-Time Permissions

What are Spectral Embeddings?

SpectralEmbeddings #SpectralLLM #ZeroTrustAI #EdgeAI #DeterministicAI #MachineLearning #AIGovernance #LinearOperators #LatentGeometry #HilbertSpace #BetaPrecision

Patterns, Anti-Patterns, and Operational Reality

Pattern: The Sidecar Contract

Pattern: Namespace Segregation by Function

Pattern: Signed Tokens Over Forwarded Credentials

Pattern: Fail-Closed by Default

Anti-Pattern: mTLS-Only Security

Anti-Pattern: Security in Application Code

Anti-Pattern: Flat Trust Zones

Operational Reality: Debugging Auth Failures

Operational Reality: Sidecar Overhead

Operational Reality: Testing Security Properties

What I'd Do Differently

Wrapping Up

Code

Atsign's Kill Switch for AI Agents Isn't Software. It's an Identity You Can Revoke.

Atsign's Kill Switch for AI Agents Isn't Software. It's an Identity You Can Revoke.

Versa's Zero Trust MCP Breaks a Core Assumption of How MCP Servers Work

Why Organizations Are Still Missing Out on Passwordless Adoption

Passwords Are Not Enough Anymore

How Does Passwordless Solve The Problem?

Why Organizations Are Lagging Behind?

No Standard Account Recovery Solution

Why Organizations Need to Prioritize Passwordless

Securing the Smile: Why Dental Systems Must Adopt Sovereign Security Trends

I. The Core Thesis (The Apex)

II. Eliminate the "Castle" Fallacy with Zero Trust

III. Decentralize Identity to Reduce Liability

IV. AI-Driven Privacy via "Librarian" Ethics

V. Conclusion: Future-Proofing with Post-Quantum Rigor

HealthTech #CyberSecurity #Web3 #ZeroTrust #DentalManagement #PADI

AI Agents Don't Have Identities. That's Everyone's Problem.

The Identity Problem

Thought Injection: A Different Kind of Intervention

Agentic Fingerprints

The Adoption Velocity Problem

What Happens When an Agent Learns From Bad Data

Getting From POC to Production

The Defense Posture

67% of zero trust implementations fail due to partial zero trust execution.

Zero Trust Reality Check: Why Implementation Failures Are Creating False Security

The Implementation Gap

The "Checkbox Zero Trust" Problem

The False Security Paradox

The Continuous Verification Challenge

AI as a Zero Trust Accelerator

The Platform Approach

Real-World Success Patterns

Phase 1: Identity Foundation (3-6 months)

Phase 2: Network Transformation (6-12 months)

Phase 3: Application Protection (12-18 months)

Phase 4: Continuous Optimization (Ongoing)

Common Implementation Mistakes

The Business Case for Complete Zero Trust

Strategic Recommendations

The Future of Zero Trust