Archive
How do we maintain granular authorisation boundaries when our serverless agentic workflows increasingly rely on third-party identity fabrics?
The convergence of Gemini Enterprise Agent Platform and Okta’s identity governance signifies a critical shift in how we must approach the security of our AI-powered workforce. We are moving away from traditional, perimeter-based security toward a model where identity is the primary control plane for every agentic interaction. As we architect serverless infrastructures on Google Cloud, the requirement to embed authentication and access controls directly into agent workflows, without resorting to bespoke, unmaintainable code, is no longer optional.
This integration highlights the necessity of centralising visibility and policy enforcement, ensuring that our AI agents operate within the same strict governance frameworks that define our human user access. The fundamental architectural principle here is the transition to "identity-aware" agent operations, where the agent's actions are cryptographically bound and policy-enforced in real time.
To realise this vision on Google Cloud, we must establish three key security pillars:
-
Cryptographic Identity Binding. Every serverless agent action must be tied to a short-lived, cryptographically verifiable token. By mapping Gemini Enterprise Agent Platform identities to Google Cloud IAM and Okta via OIDC/OAuth 2.0 token exchange protocols, we can verify the agent's context (and the delegating user's context) at every invocation boundary without relying on long-lived secrets.
-
Centralised Audit and Visibility. In an agentic workforce, audit logs must capture not just who triggered a workflow, but how the agent made decisions. Feeding token exchange logs, Gateway evaluations, and Cloud Logging streams directly into a centralised SIEM allows security teams to correlate agent behaviour with identity policies, ensuring absolute visibility and compliance.
By treating identity as the ultimate security boundary, we can confidently deploy autonomous agents that respect organisational trust boundaries and scale securely.
Are we finally moving beyond the 'Agentic Hype' phase and into the era of operationalised, sovereign agent deployments?
The announcement of the FactSet partnership with Google Cloud underscores a pivotal shift in how we architect AI-native systems. We are moving away from stateless, prompt-response interactions towards long-term, stateful agents capable of managing complex business processes like deal advisory and corporate finance. This evolution requires moving beyond simple LLM implementations and embracing a holistic platform approach that prioritises governance, memory, and, most critically, identity. As we integrate these agents into our existing cloud infrastructure, we must treat them not as ephemeral scripts, but as first-class principals within our identity and access management (IAM) frameworks.
To build reliable agentic systems, we must adhere to three foundational architectural principles that treat security as an inherent property of the agent lifecycle rather than an afterthought.
✔️ Identity-Centric Agent Governance. Agents require a verifiable, unique cryptographic identity to interact securely with cloud resources. By leveraging new Agent Identity principals, distinct from human users and service accounts, we can enforce granular, least-privilege access using Identity-Aware Proxy (IAP). This ensures that even if an agent operates autonomously, its scope of action is strictly bounded by auditable IAM policies.
✔️ Unified Security Policy Enforcement. The integration of Google Cloud with Okta for AI Agents effectively bridges the gap between enterprise identity governance and agentic execution. By delegating real-time authentication to Okta through the Google Agent Gateway, we can enforce uniform security posture across browser-based work, mobile, and desktop environments, ensuring that agentic autonomy does not create unmonitored security gaps.
✔️ Serverless Agent Runtime Orchestration. With the new Agent Runtime capabilities, we must prioritise low-latency, high-scale execution by leveraging sub-second cold starts and long-running operations. Moving agents to a fully managed, serverless platform allows us to decouple our business logic from the underlying infrastructure, effectively treating the 'agent' as the unit of scale and management, rather than the container or VM.
Ensuring these systems remain secure requires a shift towards active observability and guardrails. As we scale, the focus must remain on implementing human-in-the-loop approvals for sensitive, irreversible actions, and leveraging new defensive tools like Agent Gateway to prevent data exfiltration and prompt injection. We are building the connective tissue between our data and the agents that act upon it; our success depends on the rigour of the identity and governance framework we place around those agents today.
How does the shift towards persistent, stateful, and autonomous agentic workflows fundamentally change our requirements for perimeter-based security versus identity-centric governance?
The transition from stateless conversational bots to stateful, multi-agent orchestrations, as seen with the evolution of the Gemini Enterprise Agent Platform, requires us to rethink the standard serverless architectural model. We are moving beyond simple function execution to persistent, 24/7 background agents that require their own distinct identity, lifecycle management, and verifiable context. This architectural pivot, which leverages the Agent Runtime for long-running operations and memory-banked persistence, effectively moves the security boundary from the network perimeter to the identity of the agent itself. By integrating Okta’s identity governance with Google’s Gemini Enterprise Agent Platform, we gain the ability to map every agentic action back to a verified human owner, effectively bridging the gap between legacy enterprise IAM policies and modern, autonomous AI execution environments.
Adopting these advanced patterns demands a shift in how we approach secure execution and authorisation, moving towards a framework where security is embedded in the agent's identity rather than just the service account. We must treat AI agents as first-class principals within our IAM infrastructure, enabling granular control over the data and systems they access, thereby minimising risk while maximising the utility of agentic automation.
✔️ Cryptographic Agent Identity (SPIFFE Compliance). Moving beyond static service accounts, we are deploying agents with unique, cryptographically protected identities based on the SPIFFE standard. This ensures that every action, whether autonomous or user-directed, is fully auditable and verifiable, preventing unauthorised privilege escalation within our Google Cloud environment.
✔️ Context-Aware Governance via IAP and Agent Gateway. By utilising Identity-Aware Proxy (IAP) integrated with the Agent Gateway, we enforce access policies that go beyond network boundaries, evaluating real-time contextual signals such as device health, location, and the specific Model Context Protocol (MCP) attributes of the request. This creates a robust "air traffic control" system for our AI ecosystem, ensuring that only approved tools and agents interface with our critical data backends.
✔️ Human-in-the-Loop (HITL) for Sensitive Orchestration. We are implementing Unified Access Policies (UAP) that mandate human approval for high-risk operations, effectively neutralising the risk of autonomous "runaway" agents. This integration with Okta ensures that even when an agent operates in a background session, its capabilities are strictly bound by the permissions of its linked human owner and our organisational risk posture.
The convergence of Gemini Enterprise Agent Platform and Okta IAM offers a path towards a truly hardened, secure-by-design environment where agents act not as black boxes, but as governed, accountable participants in our enterprise workflows. We are effectively maturing from "testing" agentic potential to "productionising" high-stakes autonomous systems.
Given our current trajectory towards full autonomy in our CRM and data pipelines, how are we planning to audit the "intent" of agents that utilise long-term memory banks to make decisions based on historical data rather than just real-time input?
AI agents aren’t the risk. Unmanaged identity is.
They’re accessing systems, making decisions, and acting on behalf of users.
I’m proud to share that today, Okta is closing the security gap with the launch of Okta for AI Agents. We're bringing governance, control, and security to the agentic era. Check it out now! #OktaSecuresAI
What happens when AI agents outnumber your employees?
This question needs serious attention now. With Google Cloud partnering with Thoma Bravo to bring AI capabilities to over 115 companies and Technogym rolling out Gemini Enterprise on a global scale, the number of non-human identities is growing rapidly.
This presents a significant identity challenge because traditional IAM solutions weren’t designed for this emerging, autonomous workforce. Many of these AI agents behave unpredictably, unlike typical service accounts, which challenges established security frameworks.
Here’s what I’m observing:
✔️ Continuous Operation: AI agents don’t simply “log in” and stay put. They run around the clock, making independent decisions and interacting with multiple APIs. Security needs to focus on ongoing, real-time authorisation, not just a single checkpoint.
✔️ Probabilistic Behaviour: The next action an AI agent takes is often not predetermined, influenced by both its training data and live inputs. Authorising such unpredictable actions demands a dynamic risk evaluation approach.
✔️ The Governance Gap: Often, human identities are managed within Okta and workload identities within Google Cloud, but there’s frequently a disconnect between the two. Without an integrated view, governing AI agents that cross both environments becomes complex.
Bridging the governance of Okta’s human identities with Google Cloud’s workload capabilities is essential. This integration strengthens security across the evolving landscape of automated agents.
If you can’t estimate how many AI agents are operating in your cloud environments today, it’s a clear signal to revisit your identity strategy. 🚀
#IdentitySecurity #GoogleCloud #Okta #AI #IAM #ZeroTrust #CloudSecurity
Few weeks ago, Google Cloud introduced autonomous AI agents for threat hunting and attack path analysis designed to reduce response times from minutes to seconds.
This marks significant progress, but it also introduces a new challenge: each agent functions as a high-privilege, non-human identity making real-time decisions at machine speed.
Traditional IAM systems weren’t designed with this in mind.
The timing of these announcements stood out. Google’s AI-driven security operations were revealed on April 22, and just a week later, on April 30, Okta launched its “Okta for AI Agents” framework. This sequence underscores an important gap between infrastructure and identity governance, a topic I closely follow given my work across both areas.
These developments prompt some key questions:
✔️ What exactly is each agent, and what access should it have? ✔️ Who, or what, authorizes its actions as it learns and adapts? ✔️ How do we apply Zero Trust principles to autonomous agents? ✔️ How can we effectively audit decisions occurring at machine speed?
For cloud architects and IAM leaders, this signals the need to rethink and advance our strategies. Managing AI-driven security demands identity governance that operates at the same pace.
The chance to bring together Google Cloud’s AI capabilities and Okta’s identity framework to address this challenge is immediate.
#IdentitySecurity #ZeroTrust #GoogleCloud #Okta #AI #IAM #CloudSecurity #Okta4AIAgents
The news from Google Cloud Next '26 is exciting! Google has introduced the Gemini Enterprise Agent Platform, which provides autonomous AI agents with their own cryptographic identities, a significant step forward in identity security. You can read more about it here: https://lnkd.in/evEyRqWD.
But an identity alone isn’t enough. Every IAM and cloud security team now faces a key challenge: how to govern thousands of agents that spin up, act, and disappear in milliseconds?
Our traditional IAM approaches, built around human identities, won't cut it for this scale and speed. Here’s what we need to focus on:
✔️ Lifecycle at machine speed. Managing identities that might only be active for a few seconds.
✔️ Scoped permissions. A cryptographic ID confirms who an agent is, but governance defines what it can do. This helps prevent “shadow AI” scenarios with overly broad access.
✔️ Clear audit trails. Answering questions like: Who deployed this agent? What permissions were granted? When did access expire?
✔️ Just-in-time access. Ensuring permissions are granted only for the specific task and duration required.
✔️ Agents as first-class identities. It’s time to treat non-human identities as essential components of our security and compliance frameworks rather than technical afterthoughts.
Google has addressed the “who” question, but the responsibility for “what, when, and why”, governing these agents, now lies with us.
I’m interested to hear how other teams are preparing to manage this evolving IAM frontier. Let’s exchange ideas and experiences!
#GoogleCloudNext #AI #IAM #IdentitySecurity #GoogleCloud #ZeroTrust #Okta
If you wouldn’t let ten employees share one login, why are your AI agents sharing a single service account?
AI agents are increasingly acting like “digital workers,” operating at machine speed and making decisions that impact your systems. Yet many organisations continue to use traditional IAM approaches, leaving significant gaps in control and security.
Securing them means applying Zero Trust principles, adapted for automation and scale:
✔️ Assign each agent a unique, verifiable identity. Treat every autonomous instance as a separate worker with its own credentials and audit trail. When an agent misbehaves, you can quickly identify it and revoke only that agent’s access, avoiding wider impact.
✔️ Grant least privilege dynamically at the task level. Permissions should precisely match the job the agent performs, not broad platform access. For example, an AI summarising support tickets should only access the specific ticket IDs it’s handling, not the full database.
✔️ Implement comprehensive machine-speed logging and behavioural monitoring. Agents act faster than humans can react. Detailed logging combined with automated anomaly detection is essential to spot and respond to suspicious activity immediately.
This way, we can address the distinct risks AI agents bring, such as rapid data exfiltration, while innovating safely and keeping control as AI autonomy grows.
Would be great to hear how others are adapting their identity models to govern non-human actors effectively.
With Okta for AI Agents launching on April 30, our threat models are about to get a big shift, moving from human-speed reconnaissance to machine-speed attacks.
A compromised agent isn't limited by how fast a person can type. It can run thousands of API calls per second with legitimate credentials. This speeds up risks like privilege creep and the classic "confused deputy" problem, where logs show what a service account did, but not why or on whose behalf.
Getting ahead of this requires a hands-on approach. Here are the critical controls teams bridging Okta and GCP should be implementing now:
✔️ Use GCP IAM Conditions to enforce granular restrictions. For agents, this means going beyond source IP and using attributes like `https://lnkd.in/etAzbG4A to link actions back to a specific user, directly solving the 'confused deputy' audit gap.
✔️ Create separate BigQuery log sinks for agent vs. human activity. This helps baseline "normal" agent behaviour now, so you can spot anomalies the moment they happen.
✔️ Implement agent-specific lifecycle management. This means setting hard expiration dates, enforcing 90-day access reviews, and having automated ways to disable accounts.
✔️ Enforce least privilege with finely-tuned roles. An agent that only needs to read data should have a bigquery.dataViewer role, not bigquery.admin.
Okta for AI Agents will handle the identity governance, while GCP's IAM provides the crucial infrastructure guardrails. Real success in this new era depends on having the expertise to implement security across both ecosystems.
I keep asking my teams: If an AI agent were compromised tomorrow, how would we find out?
Would love to hear your thoughts on preparing for this shift.
The era of GenAI "pilot purgatory" is officially over. The new mandate? Scaling and governing networks of autonomous agents.
I just published an article breaking down the biggest architectural shifts:
🤖 Gemini Enterprise Agent Platform: Moving from monolithic prompts to multi-agent orchestration via the new ADK. ⚡ 8th-Gen TPUs: The new TPU 8i is purpose-built for lightning-fast agent inference and memory recall. 🛠️ Workspace MCP Server: Programmatically integrate Drive, Docs, and Calendar logic into your custom AI apps. 🛡️ Autonomous Security: Purpose-built agents for proactive threat and fraud intelligence.
Read the full architectural breakdown, implementation guide, and pros/cons analysis here: https://lnkd.in/ebFWmen6
#GoogleCloudNext #GenerativeAI #CloudComputing #SoftwareArchitecture
If your security strategy relies solely on "being inside the VPC," you’re one compromised container away from a total breach.
I just published Part 2 of my Service Mesh series: mTLS & Zero Trust.
In this installment, I break down how to move away from blunt VPC firewalls and implement cryptographically verified identities for Cloud Run using SPIFFE and Managed mTLS.
We’re diving into the "Zero Trust" requirements of a production mesh:
✅ The Identity Framework: Why SPIFFE IDs and short-lived certificates are the only way to scale trust across regional boundaries. ✅ Automated Handshakes: How to leverage Google’s Certificate Authority Service (CAS) for zero-touch certificate rotation—no manual key management required. ✅ L7 Authorization: Moving beyond ports to enforce fine-grained Method and Path-based policies. Stop a DELETE request at the sidecar level before it ever hits your application logic. ✅ The Migration Blueprint: My GDE-level guide for moving from Permissive to Strict mTLS mode on a live system with zero downtime.
In a modern serverless architecture, an IP address is just a temporary label. If you want true security, you need a signature.
Read the full guide here: https://lnkd.in/em2P_X6D
#GoogleCloud #CloudRun #ZeroTrust #CyberSecurity #ServiceMesh #Serverless #CloudArchitecture #SRE #DevOps
The more an organisation expands into the cloud, the smaller its IAM perimeter should actually get.
As teams spin up new Cloud Run services, GKE clusters, and SaaS integrations like Teamcenter on GCP, the attack surface grows exponentially.
According to a recent article in The Hacker News, this results in what they call "Identity Dark Matter," referring to nearly 46% of identity activity that remains invisible and unmanaged.
The strategic response isn't to try and control every single service; it’s about shrinking the perimeter through consolidation:
Establish a single source of truth. All human and machine identities must flow through one authoritative system, like Okta federated with Google Cloud Identity.
Shift to policy-based access. Grant permissions based on context (who, what, where, when), rather than managing access for every individual resource.
Eliminate standing privileges. Use Just-in-Time access for resources when needed, leaving no persistent permissions to exploit.
Automate the identity lifecycle. Access is granted on hire, modified on role change, and revoked on termination, automatically.
This is especially critical as machine identities continue to multiply. Traditional methods, like managing service account key files, don’t scale well. Instead, we rely on tools such as GCP’s Workload Identity Federation, which enforces strong, short-lived credentials.
By consolidating and improving intelligent visibility, we can better secure a cloud environment that’s always evolving.
#Okta #GoogleCloud #IdentitySecurity #IAM #CloudSecurity #ZeroTrust #WorkloadIdentity
With breaches showing how quickly attackers can take advantage of forgotten credentials, having a true understanding of what’s inside your environment matters more than ever. Many organisations overlook the scope of non-human identities: API keys, OAuth apps, and automation scripts quietly operating behind the scenes.
Here are five critical questions I encourage teams to reflect on:
-
Do you have a precise count of your non-human identities?
-
Are you confident that recently deprovisioned employees no longer have access? (Try verifying this manually on one case across your top five critical systems).
-
How quickly can you revoke access for a compromised privileged account? (If it takes more than 15 minutes, it’s time to automate further).
-
Can you produce an access report for sensitive data repositories in under 30 minutes, covering the last 30 days?
-
Are your highest-privilege users secured with phishing-resistant authentication? (Aim for at least 80% of your top 10 admins using passkeys or FIDO2.)
Don’t feel pressured to fix everything at once. Start by answering these questions honestly and identify your largest gap.
If you’re tackling any of these challenges and want to exchange ideas, I’m happy to connect.
Disclosure from Palo Alto Networks Unit 42 about the "Double Agent" vulnerability affecting Google Cloud's Vertex AI Agent Engine: https://lnkd.in/ehs8_jNm
This is a clear example of where cloud infrastructure and identity security meet. The issue boils down to a core IAM misconfiguration: default service accounts having overly broad permissions.
Because of this, a compromised AI service could access all Cloud Storage buckets in the project and even parts of Google's internal infrastructure without restriction.
For GCP architects and security teams, here are some important steps to take:
✔️ Review all your service accounts, especially those linked to AI workloads. Avoid relying on default accounts.
✔️ Follow the least-privilege principle by assigning custom service accounts with narrowly defined permissions for each AI workload.
✔️ Turn on Data Access audit logs to spot any unusual activity from AI-related service accounts.
✔️ Treat AI service identities with the same care and scrutiny as human user accounts.
Using custom service accounts like BYOSA helps teams experiment with AI capabilities securely by applying tried-and-true IAM practices to this evolving area.
#GoogleCloud #VertexAI #IAM #IdentitySecurity #CloudSecurity #AI
Google Cloud's 2026 forecast highlights AI agents as distinct digital identities, an emerging reality we are already encountering.
Traditional identity management was designed around human behaviours with predictable patterns and fixed access schedules. AI agents introduce a new set of complexities:
- High request volumes (thousands of API calls per minute)
- Autonomous decision-making
- Continuously shifting access requirements
- Intricate audit trail demands
These raise important technical challenges: Should we rely on OAuth tokens or service account keys? How do we enforce least-privilege when goals evolve constantly? What constitutes typical behaviour for an autonomous agent?
Okta's CEO has emphasised the growing need for an "AI-agent kill switch" as a vital security control. Developing this demands expertise that spans identity platforms like Okta and AI infrastructure on Google Cloud.
This intersection is where secure innovation is being shaped.
If you’re interested in how Okta and Google Cloud are addressing these evolving identity challenges, I’d be glad to discuss the opportunities ahead.
#IdentitySecurity #GoogleCloud #Okta #AI #IAM
Interesting forecast from Google Cloud in their "Cybersecurity Forecast 2026": automated, scalable cyberattacks are expected to become the norm.
This highlights a growing blind spot for many organisations: AI agents.
Customer service bots, data analysts, and other automation tools function as powerful service accounts. Yet, the same identity governance we apply to human users often doesn’t cover these digital identities adequately.
Deploying AI agents without a solid identity framework increases the risk of automated attack vectors.
A few key things to keep in mind:
AI agents are privileged identities at scale. They access critical systems and data, and without proper governance, each agent could be hijacked and turned into a threat.
Google Cloud provides strong controls for this. Features like Workload Identity Federation, Service Account Impersonation with short-lived credentials, and Identity-Aware Proxy (IAP) are vital for securing AI workloads and internal endpoints.
A compromised agent can accelerate breach risk. It can carry out malicious actions much faster than human attackers, often without detection until after the fact.
For IAM leaders, CISOs, and cloud architects, now is the time to inventory your AI agents. Understand ownership, system access, and whether their identities follow least-privilege principles.
I’m happy to share that on April 30th, Okta will launch its AI Identity Blueprint, providing guidance and tools to help organisations build governance frameworks tailored to this emerging challenge.
Treating AI agents as distinct digital identities is key to keeping innovation secure. 🚀
#IdentitySecurity #GoogleCloud #AI #IAM #Cybersecurity #Okta #OktaforAIAgents
Google Cloud Next ’26 is coming up fast in Las Vegas! (April 22-24) 🚀
There will be plenty of new features announced, but for those of us focused on IAM and cloud leadership, it’s about preparing the right questions in advance rather than trying to catch everything on the fly.
Here’s the simple, strategic plan I'm using to prepare:
First, audit the current GCP footprint. Which services are you using? How do users and service accounts authenticate? Document all the identity integration points and pain points now.
Next, define 3 specific questions you need answered. For example, "How can we automate the service account lifecycle in GKE clusters?" or "What new AI-powered security features can strengthen our Zero Trust model?
Then, pre-identify high-value sessions. I'm looking for deep dives on Zero Trust, GKE modernisation, and security where I can get those questions answered by Googlers and peers.
Finally, block out time on Friday, April 25th. That time is dedicated to documenting takeaways and updating your roadmap.
The real value from Next comes not from the announcements, they’ll be available on the official blog, but from having your prepared questions addressed by the experts in the room.
I’ll be closely following the identity and security implications of all the infrastructure updates.
If you’re heading to Next, I’d love to hear about what challenges you’re prioritising.
#GoogleCloudNext #IAM #IdentitySecurity #CloudStrategy #ZeroTrust #GoogleCloud
With a flood of announcements from Google Cloud, Okta, Wiz, and Rubrik, it's becoming clearer how the layered architecture for securing autonomous agents needs to come together. This is an important topic, especially as Mandiant’s M-Trends 2026 report highlights that the attacker handoff window has shrunk to just 22 seconds.
I've found it useful to think about this as a 4-layer stack, with Identity right at the centre:
✔️ Infrastructure: Google Cloud and Wiz establish a secure runtime foundation. This encompasses everything from vulnerability detection in AI workloads to network segmentation for agent communications, focusing on whether the underlying infrastructure is secure.
✔️ Identity: At the core of control, Okta for AI Agents (GA on April 30) manages agent registration, lifecycle, and authentication of these non-human identities. It delivers audit trails for autonomous decisions and addresses the question: Who are my agents, and how do I control their access?
✔️ Intelligence: Google Cloud’s Gemini combined with Mandiant provide machine-speed threat detection and response. This is critical for addressing AI-specific attacks and figuring out if detection and response can outpace attackers.
✔️ Governance: Rubrik SAGE completes the cycle by enforcing policies, monitoring agent decisions, and controlling data access to make sure agents operate within established parameters.
These layers don't work in isolation. Okta identity decisions can dynamically influence Google Cloud's security policies. Likewise, threat intelligence from Google and Mandiant can trigger immediate identity revocations. Everything works together as a unified system.
All of this underscores an essential point: securing systems effectively depends on identifying what and who is interacting within them. Identity remains the central control point governing every interaction an agent has across this stack.
As more organisations begin deploying AI agents, focusing on an identity-first approach is crucial to maintaining control and accountability.
Microsoft's forecast estimates there will be around 1.3 billion AI agents active in enterprises by 2028.
These AI agents represent a distinct new workforce. 🤖 For those of us already dealing with service account sprawl, imagining a billion autonomous identities running at machine speed highlights a significant challenge ahead.
The conversation is moving quickly, and several points stand out:
✔️ AI agents are emerging as a new identity category. We need to shift our thinking from traditional "user personas" to "agent personas." Current IAM approaches aren’t designed for agents with autonomous behaviours and short-lived lifecycles.
✔️ Zero Trust needs to encompass AI. Cisco’s presence at RSAC underscored this with their focus on agent registration, ongoing policy enforcement, and assigning accountable human owners.
✔️ Automation is essential. Managing identity lifecycles at the speed and scale AI agents require calls for automation. Using Okta Workflows to handle onboarding, permissions, and decommissioning on GCP infrastructure is a practical way to reduce risk here. 💡
The adoption gap is notable. Cisco’s research indicates while most enterprises are experimenting with AI agents, very few have deployed them securely in production.
For IAM and cloud leaders, evolving identity strategies to manage this new type of workforce is becoming a priority.
Preparing policies for the agent workforce will be a major focus area moving forward.
On April Fools' Day, it’s interesting to look back at one of the earliest known pranks. In 1698, crowds gathered at the Tower of London after hearing about the "washing of the lions." Of course, no lions were actually washed.
Today, some prevalent myths in our industry create a similar sense of false security. Here are three that I encounter frequently:
Myth 1: "We deployed MFA, so we're secure." Threat groups like Scattered Spider have become highly skilled at bypassing traditional MFA methods, especially those relying on SMS or basic push notifications through real-time phishing and MFA fatigue attacks. It’s important to recognise that not all MFA factors offer the same level of protection.
Adopting phishing-resistant authenticators such as FIDO2 and passkeys is key. These provide hardware-backed security that effectively blocks advanced attacks. 🔒
Myth 2: "We bought a Zero Trust tool, so we have Zero Trust." Zero Trust is a framework and approach, not something that happens by simply acquiring a product. Implementing real Zero Trust requires building an architecture based on continuous verification and "never trust, always verify" principles.
At the heart of this is identity as the control plane. This involves setting adaptive policies that evaluate user context and device health, alongside Identity Security Posture Management to continually monitor and mitigate risks.
Myth 3: "Cloud security is the provider's problem." This overlooks the shared responsibility model. While cloud providers like Google Cloud safeguard the underlying infrastructure, your organisation retains responsibility for securing identity, access, data, and applications.
Mastering IAM setups is essential. Federating Okta with GCP via Workload Identity Federation centralises access governance and enforces strong MFA and device trust, helping to eliminate the risks tied to long-lived credentials.
With attackers constantly evolving, establishing a strategic, phishing-resistant identity posture is foundational to a resilient security stance.
If you’d like to discuss how these ideas can be applied in real environments, feel free to reach out.
#IdentitySecurity #ZeroTrust #CloudSecurity #PhishingResistant #IAM #Okta #GoogleCloud
A question worth asking: if an AI agent deleted 10,000 records at 3 AM, could you confidently identify which permission allowed it and restore that permission to its state from the day before? 🔒
AI agents have become autonomous entities within our enterprise IAM systems like Okta and Entra ID, making thousands of access decisions every hour and continuously interacting with APIs and sensitive data.
Our backup strategies, however, haven’t evolved at the same pace. While we preserve data backups, the full state of these agents—their identity, authority, and access history—is often not captured.
Okta’s recently shared Showcase 2026 blueprint on securing AI agents highlights some key adjustments we need to make:
✔️ Backing up Identity Configs: Export service account configurations through Okta to track which agents exist, their permissions, and authentication methods. This enables precise restoration or audit of an agent’s access footprint.
✔️ Logging Access Patterns: Route AI agents’ system log events to tools like Google Cloud Logging for historical records that aid analysis and anomaly detection.
✔️ Version-Controlling Policies: Keep permission manifests in Git to make change management auditable and enable "identity rollbacks.
✔️ Applying Zero Trust for AI: Enforce stricter security policies for AI agents beyond standard service accounts, including least-privilege access, time-limited permissions, and documented justifications for each permission.
These practices are essential. Without capturing the full identity state of an AI agent, incident investigations, compliance verification, or breach mitigation become seriously challenging. It’s crucial to treat identity as a fundamental part of your backup and recovery approach.
Extending Zero Trust principles to AI agents means never trusting by default, always verifying, and maintaining comprehensive visibility over their access lifecycle.
What steps is your team taking to evolve backup and identity governance for AI agents? I'm happy to connect and exchange ideas!
#Okta #IdentitySecurity #ZeroTrust #AI #CloudSecurity #IAM #GoogleCloud #OktaforAIAgents
As AI agents move from simple assistants to an autonomous workforce, identity security is facing a new frontier. "Shadow AI" and unmanaged non-human identities are real risks that require a new playbook.
Securing the "Agentic Enterprise" isn't just about the tech, it's about ensuring every AI agent has a managed identity.
#Okta #IdentitySecurity #AIAgents #CyberSecurity #IAM
Interesting to see the market reflecting a trend we're noticing firsthand.
BMO Capital recently upgraded Okta's stock, highlighting AI agent identity management as a significant driver for growth. This area really excites me because it sits right where Okta and Google Cloud infrastructure intersect.
As enterprises deploy more AI agents on platforms like Cloud Run, Cloud Functions, and Vertex AI, these agents form a new kind of digital workforce. Like human users, they require a secure identity lifecycle.
Here’s how we can approach governing them with tools we already have:
✔️ AI-driven attacks are rapidly becoming a leading identity concern, surpassing stolen credentials, making agent security essential. ✔️ Okta Workflows can automate the full agent lifecycle: provisioning identities upon deployment, rotating credentials according to usage, and cleanly deprovisioning them when retired. ✔️ Using Okta as the IdP alongside GCP’s Workload Identity Federation enables agents to access service accounts via fine-grained IAM policies, removing the need for risky manual key handling. ✔️ Organisations that already use Okta for human identities have a solid platform to secure their AI agents, no extra tools required.
It’s rewarding to help teams expand on their existing Okta and Google Cloud investments to address this evolving challenge safely. The same platforms protecting employees also offer control and confidence over the growing AI workforce.
If you’re working on AI agent governance and want to share insights, feel free to reach out. I’m happy to exchange what we’re learning.
#Okta #GoogleCloud #IdentitySecurity #AI #IAM #WorkloadIdentity #CloudSecurity
Google's acquisition of Wiz, completed on March 11, signals a big change in how multicloud security is approached. For identity teams, the separation between identity security (“who”) and infrastructure posture (“what”) is becoming less distinct. 💡
Wiz’s agentless scanning across AWS, Azure, and GCP offers real-time insight into resource posture. When you bring together the "who" (identity signals from a platform like Okta) and the "what" (resource data from Wiz), security decisions become much more informed.
This integration shifts security from a reactive mode to a more proactive stance. It helps identify risky setups, such as a vulnerable VM paired with an admin service account, before these can be exploited.
As cloud providers continue to consolidate, having a neutral, cross-cloud IAM platform gains importance. Managing orchestration wisely is now an advantage, not an obstacle.
This marks a significant step forward for identity teams. It’s a strategic moment to incorporate infrastructure signals right into our access policies, increasing their intelligence and context-awareness.
Organisations that successfully combine specialist capabilities with platform security will set themselves apart. Building a strong security framework that supports ongoing innovation is key. 🚀
I’d be glad to connect and explore what this means for your multicloud approach!
#GoogleCloud #Wiz #Okta #IdentitySecurity #Multicloud #IAM #CyberSecurity #CloudSecurity
If an AI agent makes a critical decision in your system, who is responsible?
As AI agents become more autonomous, traditional Identity and Access Management (IAM) frameworks face new challenges. These agents are evolving beyond simple service accounts into distinct identities, yet they lack HR-driven lifecycles and defined roles. This marks the rise of what some call the "agentic enterprise.
Treating these agents as true identities means addressing three key challenges:
⚙️ Lifecycle Management Without HR Systems AI agents are created by development teams or CI/CD pipelines on platforms like Vertex AI, rather than through systems like Workday. Who signs off on their identity? And who retires them once a project wraps up? Without a central governance model, these agents risk accumulating unchecked—a phenomenon sometimes referred to as "Shadow AI.
💡 Defining "Least Privilege" for Autonomous Actions Rather than fitting into traditional roles, agents are task-driven. This calls for moving away from static permissions towards dynamic, intent-based policies that grant only the access necessary for specific actions. Such precision is essential to minimise risk and avoid privilege creep.
🔒 Audit and Compliance Attribution When an agent interacts with data, responsibility can be murky—is it the data scientist who designed it? The business owner who deployed it? Effective audit trails should link agent actions back to the humans or processes behind them, along with the intended outcomes.
Addressing these challenges is fundamental to adopting AI-driven automation securely. Okta’s blueprint and the forthcoming "Okta for AI Agents" platform offer a framework to manage this new identity category, including discovery, governance, and a "universal logout" capability to swiftly reduce risk.
How are your teams managing governance around "Shadow AI" in practice?
#IdentitySecurity #AI #IAM #Okta #CyberSecurity #ZeroTrust
What happens when your workforce includes more than just humans? 💡
We're stepping into a reality where AI agents act autonomously within our cloud environments. According to a recent Hyperframe Research survey, 88% of organisations have encountered security incidents involving AI agents, yet only 22% recognise them as identity-bearing entities. This creates a significant governance blind spot.
Traditional IAM secures the user, but how do we control the autonomous agents operating on their behalf, accessing databases like AlloyDB or invoking APIs in Google Vertex AI?
I’m excited that Okta has introduced a new blueprint for AI Agents, announced on March 16 and launching in April, designed to evolve security from an identity-based model to one focused on intent by managing agent-specific identity lifecycles.
Here’s what it includes:
✔️ Discovery & Registration: Identify and onboard all agents, approved or shadow, to gain full visibility.
✔️ Access Control: Implement least-privilege access with detailed API token management, eliminating tangled shared service accounts.
✔️ Universal Kill Switch: Quickly revoke an agent’s credentials everywhere if risky activity is detected.
✔️ Governance Workflows: Extend established IAM processes like access reviews and certifications to your emerging AI workforce.
Bridging Okta and Google Cloud as a technical strategist, I view this as an essential advancement to secure the sophisticated, automated workflows our customers are building. It empowers teams with precise control required for safe innovation.
Identity is growing to embrace this new class of autonomous workforce.
#Okta #IdentitySecurity #AI #CloudSecurity #IAM #GoogleCloud
As AI agents become more autonomous, a critical question emerges: How do you apply Zero Trust to an identity you can’t see?
Many organisations are now recognising a growing blind spot around AI agent security incidents. Many of these agents operate with privileged access but without a formal identity, creating significant risk.
That's why I'm excited that Okta unveiled a new blueprint on March 16, to tackle this head-on. This is about treating AI agents as first-class, non-human identities and applying the same Zero Trust rigor we use for people.
Here’s the core framework behind Okta for AI Agents (launching April 30):
✔️ Where are your AI agents? Discover both authorised and “shadow” agents by onboarding them as distinct identities in your Universal Directory.
✔️ What can they connect to? Govern connections to resources like Vertex AI, BigQuery, and AlloyDB through a centralised Agent Gateway that enforces least privilege.
✔️ What can they do? Control and audit agent actions with automated workflows, detailed logs, and a universal “kill switch” to instantly revoke access.
For teams building on Google Cloud, this means we can finally integrate AI agents running on Vertex AI with backend systems like BigQuery or AlloyDB under strict, auditable identity governance. It’s impossible to secure what you don’t know. 🚀
Teams that establish strong identity governance for their AI agents now are building a more secure and resilient foundation for the future.
I’m looking forward to discussing how this framework fits practical deployments across Google Cloud and Okta. If you’re planning to bring your AI agents under control before the April 30th GA, I’d love to hear your thoughts.
#Okta #GoogleCloud #IdentitySecurity #AI #ZeroTrust #IAM #VertexAI
What happens when your most active 'users' aren't even human?
AI agents are appearing faster than identity teams can properly govern them, raising compliance and security concerns. For example, when TransUnion launched its AI analytics agent in partnership with Google Cloud, it revealed a new situation: a single service may involve hundreds of autonomous identities needing oversight.
The problem? Traditional IAM just wasn’t designed for this.
The human identity lifecycle: hiring, role changes, terminations, doesn’t align with AI agents’ lifecycle, which involves creation, frequent version updates, cloning, and often no clear retirement process. This leaves many organisations unaware of "shadow AI" running with broad, persistent permissions.
This presents a real challenge but also a chance to advance our identity strategies. Breaking it down:
💡 Lifecycle Mismatch: Manual processes can’t keep pace. Without automation, orphaned or unmanaged agents multiply, each posing a security risk.
💡 Accelerated Permission Sprawl: AI agents gather permissions with each new version, making it tough to uphold the Principle of Least Privilege and increasing the attack surface.
💡 The Audit Nightmare: How do you respond to a regulator asking, "Who accessed this PII?" when logs read something like "GenAI-Analytics-Prod-v2.3-Instance-4719"? Tracing accountability becomes difficult.
The key is creating a "birth certificate" system for every agent—a mandatory registry capturing its purpose, ownership, data scope, and version.
From there, we can automate the lifecycle with tools like Okta Workflows, safeguard access using short-lived credentials through GCP Workload Identity Federation, and apply data access controls with AlloyDB’s row-level security. 🔒
As the "Agentic Enterprise" era unfolds, identity teams need to shift from human-centric processes toward automated governance treating AI agents as full-fledged identities.
#IdentitySecurity #IAM #AIGovernance #Okta #GoogleCloud #ZeroTrust #CloudSecurity
Interesting read on the two actively exploited Chrome zero-days patches (CVE-2026-3909 and CVE-2026-3910).
Here’s a detailed update from the Chrome security team: https://lnkd.in/eqzsgup4.
It’s a strong reminder that browser compromises can undermine traditional security measures, even when patches are applied promptly.
Zero Trust architecture plays a vital role in this landscape by assuming breach scenarios and focusing on identity as the key control point.
When an endpoint is compromised, using phishing-resistant authentication helps ensure identity is verified on every access attempt.
Combining Okta’s identity security capabilities with Google Cloud infrastructure supports a layered security approach that focuses on proactive defence, not just reacting to risks. 🔒🚀
#IdentitySecurity #ZeroTrust #Okta #GoogleCloud #Cybersecurity #PhishingResistant
After earning 9 Google Cloud certifications, I’m excited to share a few insights that no exam could ever test.
In real-world cloud environments, where identity has become the new perimeter, the gap between knowing how to set a permission and running a secure, scalable identity strategy remains huge.
Here are 5 unexpected lessons from my journey that have stuck with me:
💡 Governance over configuration From my experience, many GCP security issues stem less from policy misconfiguration and more from gaps in governance strategy. Who approves access? For how long? GCP IAM defines what’s possible; Okta controls when and under what conditions that access is granted.
🔒 Service accounts are the silent risk In several customer environments I've audited, service accounts often outnumber human users by multiples, frequently lacking proper lifecycle management. The classic case: a developer creates a service account, downloads a JSON key, commits it to a public GitHub repo, then leaves. That key remains active, often unnoticed.
🔗 The missed Workspace + GCP connection Many organisations use Google Workspace for email and docs but manage GCP access separately. They overlook the valuable integration where Workspace Groups can govern GCP project access via Okta, centralising governance and closing a preventable gap.
⚙️ Workload identity at the database level Preparing for the Professional Cloud Database Engineer certification reinforced this for me. Every database connection should authenticate as a distinct identity with minimal permissions, avoiding reliance on shared, vulnerable credentials. It’s a crucial part of identity-first security.
🚀 Automation is what really counts Certifications focus on manual tasks. But enterprises need Infrastructure-as-Code, automated governance, and self-service workflows. The shift is from “I know how to do this” to “I can automate this so no one has to do it manually ever again.”
Ultimately, these certifications were important milestones. Their true value lies in developing mental models to tackle identity challenges that customers haven't even recognised yet, helping move from learner to strategist.
I’d love to hear your thoughts on unexpected identity risks that formal training might not cover.
#GoogleCloudCertified #IdentitySecurity #IAM #CloudArchitecture #Okta #ZeroTrust
For years, achieving true high-availability (HA) between Cloud Run services meant stitching together complex VPC peering or settling for slow DNS failover.
We can do better.
I just published Part 1 of my new series: "The Global Service Mesh.
In this guide, I break down how to use Cloud Service Mesh (formerly Traffic Director) and the new Service Routing APIs to build a system for your serverless infrastructure that spans the globe.
✅ The Architecture: Why native Serverless NEGs and INTERNAL_SELF_MANAGED backends are the key to client-side load balancing. ✅ The Resolution: How to configure Private DNS zones to map custom hostnames (like orders.mesh) to Mesh VIPs. ✅ The Managed Proxy: How to leverage Direct VPC Egress for zero-config mesh participation—no manual Envoy sidecars or complex bootstrap files required. ✅ The Logic: How to split traffic 90/10 across regions globally without touching a single line of application code.
If you are running mission-critical workloads on Serverless, this is the modern architecture you should be looking at.
Read the full guide here: https://lnkd.in/ewx7Xqqy
#GoogleCloud #CloudRun #ServiceMesh #Serverless #CloudArchitecture #DevOps #SRE
AI agents are now some of your busiest “workers”, accessing databases, executing workflows, and making decisions around the clock. But many organizations are deploying them without proper identity controls.
Unlike a human user, a compromised AI agent credential can cause automated, widespread damage at machine speed. This growing security gap means we need to rethink our IAM strategy.
To secure AI agents effectively, especially on Google Cloud, here are a few essentials:
✔️ Assign each AI agent a unique digital identity. Sharing service accounts breaks auditing and accountability.
✔️ Apply least-privilege access—agents should only get permissions for their exact tasks.
✔️ Manage the full lifecycle of AI identities, from onboarding and secret rotation to decommissioning when projects pause.
✔️ In Google Cloud, use Workload Identity for GKE workloads, letting pods authenticate securely without static credentials.
✔️ For serverless AI, follow service account best practices in Cloud Functions and Cloud Run, limiting permissions and enabling automatic key rotation.
✔️ And when it comes to data access, control AI connections to services like AlloyDB through identity-based policies.
Identity is the key control point for securing autonomous agents throughout cloud infrastructure.
I’m interested in hearing how teams are evolving their identity strategies to handle this new wave of autonomous AI agents.
With market pressure on identity vendors, enterprise leaders require Zero Trust implementations that deliver measurable value quickly instead of lengthy programs that struggle to demonstrate ROI.
To keep a Zero Trust journey on track, consider these three key questions:
-
What's your current identity attack surface?
Organisations often lack visibility into how many applications have SSO enabled, which users have MFA activated, or what portion are using phishing-resistant authenticators. Establishing these baseline metrics is crucial for tracking progress. Identity Security Posture Management provides real-time insights. -
Which business process or compliance requirement is driving this initiative?
Zero Trust projects that start with "because it's best practice" frequently miss the mark. Successful projects connect to clear outcomes, such as meeting DORA compliance, protecting integrations after mergers and acquisitions, or securing access for offshore teams. Defining this focus helps scope the project and set meaningful success criteria. -
Do you have automation to maintain Zero Trust at scale?
Zero Trust requires continuous verification. Relying on manual onboarding, access reviews, and policy updates does not scale effectively. Automation, like Okta Workflows for access reviews or orchestrating identity lifecycle management for GCP services such as AlloyDB, is essential.
Starting with a clear framework helps avoid resource-heavy projects that fail to deliver value.
#Okta #GoogleCloud #IdentitySecurity #ZeroTrust #Automation #CloudSecurity
After years of industry hype, we are beginning to settle into a clearer understanding of what "Zero Trust" means. This shift translates into practical steps for Google Cloud Platform (GCP) infrastructure beyond the usual buzzwords.
The essential change moves from "trust but verify" to "never trust, always verify." With remote work and cloud adoption altering the perimeter, we can no longer assume inherent trust. Trust must be explicitly established at every workload, user, and request.
Here’s a snapshot of how this looks on Google Cloud:
✔️ GKE Clusters: We have moved away from implicit pod-to-pod trust by adopting Workload Identity for each pod. This involves encrypted, authenticated calls via service meshes such as Istio or Anthos and replacing broad cluster-admin roles with fine-grained service-specific policies.
✔️ Cloud Run Services: Instead of relying on the default compute service account with wide Project Editor rights, create dedicated service accounts per service with precise invoker permissions and block all unauthenticated access. The focus is shifting from public URLs to authenticated, policy-enforced endpoints.
✔️ Human Access: Traditional MFA is no longer sufficient. The current standard involves phishing-resistant authenticators like security keys or passkeys. Pairing this with context-aware access and just-in-time privilege elevation ensures that admins do not retain standing Owner permissions.
✔️ Automation Reduces Friction: While some may worry that Zero Trust introduces extra friction, automation is what makes it manageable. Workload Identity alleviates the burden of handling service account keys, and policy-as-code makes enforcement consistent and efficient.
Successfully adopting this approach requires close collaboration between DevOps, Security, and Application teams. It begins with understanding your current status—are your GKE pods using Workload Identity? Which workloads carry the most risk? From there, you can mature your access policies based on continuous verification.
Zero Trust is steadily becoming the security baseline that addresses weaknesses left open by older models.
Happy to share experiences and insights on combining identity strategy with GCP infrastructure. 🚀
#GoogleCloud #ZeroTrust #GKE #CloudRun #IdentitySecurity #WorkloadIdentity
Security that only works for the most tech-savvy users falls short of its goal.
AI-driven phishing attacks are becoming increasingly convincing, moving beyond the obvious spelling mistakes we used to rely on as red flags. This trend creates heightened risks for vulnerable groups such as older adults, non-native English speakers, and individuals with cognitive challenges, who often find themselves disproportionately targeted.
Our industry is evolving. Instead of solely focusing on "educating the user," we are moving towards authentication solutions that prioritise simplicity and accessibility without compromising security. The aim is clear: phishing-resistant authentication should become the baseline for everyone.
-
Passkeys and WebAuthn exemplify this approach by removing the mental effort involved in entering codes or identifying fraudulent links. For users facing barriers, this shift makes a significant practical difference.
-
Platform authenticators like Face ID and Windows Hello are designed for ease, relying on quick biometrics and shifting trust from the user’s vigilance to technology that just works.
-
Hardware security keys provide a straightforward, universal action that transcends language and literacy differences.
At scale, solutions like Okta’s phishing-resistant authenticators and Google Cloud’s device trust policies empower teams to deliver security that includes everyone. Identity Security Posture Management provides visibility into users still relying on less secure methods, helping organizations guide them to safer options.
Making security accessible to everyone combines protection with practical innovation. It’s an essential step toward a more inclusive and safer digital environment.
#IdentitySecurity #Accessibility #Okta #GoogleCloud #IAM #PhishingResistant #WebAuthn #Passkeys
Non-human identities, such as service accounts, AI agents, and API tokens, now outnumber human users by roughly 10x in many enterprises. This "silent workforce" continues to process data and make API calls even when human activity slows.
Traditional IAM systems weren’t designed for this landscape. There’s no joiner-mover-leaver lifecycle, no designated approvals, and no user to complete MFA—resulting in many over-privileged accounts that rarely see reviews.
Here’s a practical framework to regain control:
✔️ Discover: Identify every non-human identity, including unmanaged AI agents, by using tools like Okta's Agent Discovery and Google Cloud IAM audits.
✔️ Document: Assign clear ownership and document the purpose of each agent to ensure accountability.
✔️ Govern: Enforce least privilege access and apply time-bound permissions to reduce potential risk.
✔️ Automate: Leverage Okta Workflows alongside Google Cloud Functions to implement policies and streamline identity lifecycle management.
✔️ Monitor: Maintain continuous oversight by auditing activity via Security Command Center and Okta audit logs to catch irregularities early.
Protecting these automated identities is becoming increasingly important.
If you want to discuss how this approach can enhance your governance of non-human identities, feel free to reach out.
#IdentitySecurity #IAM #AI #Okta #GoogleCloud #Cybersecurity
Alphabet is set to more than double its capital expenditure to around $175-185 billion in 2026, indicating significant developments ahead for Identity and Access Management.
This level of investment underscores Google’s commitment to advancing enterprise cloud and AI capabilities. As Google Cloud and AI workloads grow rapidly, new identity challenges are emerging. The traditional IAM model, primarily designed for human users, now faces the complexities introduced by autonomous AI agents that require secure identity handling.
Here are some key shifts to note:
✔️ AI-driven identity decisions: Static access rules are evolving. AI models will increasingly make real-time access decisions by analyzing behavior and risk, making integration between Google Cloud AI and identity platforms like Okta essential for detecting anomalies.
✔️ Securing the AI workforce: Autonomous AI agents will require their own identities. This necessitates governance practices focused on tightly-scoped service accounts, API-level access controls, and detailed audit trails for every action taken by these agents.
✔️ Zero Trust for AI pipelines: Managing security for AI pipelines involves controlling permissions over training jobs, model endpoints, and sensitive data. Google Cloud’s Workload Identity Federation and Okta's API Access Management will work together to enable secure, automated workflows.
✔️ IaC meets Identity automation: The expansion of cloud environments drives more automated deployments. Integrating Okta Workflows with tools like Google Cloud Deployment Manager ensures that infrastructure is provisioned securely and scales efficiently.
This investment highlights the increasing importance of expertise in both identity security and cloud infrastructure. Organizations building on Google Cloud will benefit from partners who understand these interconnected domains.
As someone who thrives at this intersection, I am eager to tackle the challenges ahead. It would be great to hear how others are approaching their IAM strategy in the era of autonomous AI.
#IdentitySecurity #GoogleCloud #Okta #AI #IAM #ZeroTrust
The predictions for 2026 indicate a significant transformation in the cybersecurity landscape due to AI-powered phishing.
Attackers are leveraging AI to create highly targeted spear-phishing campaigns at scale, effectively eliminating the grammar mistakes that previously exposed them. They are also employing AI-cloned voices for hyper-realistic "vishing" calls.
This evolution highlights the inadequacy of traditional MFA methods:
✔️ SMS Vulnerabilities: SIM swapping and SS7 protocol exploits allow attackers to intercept one-time codes.
✔️ TOTP Risks: Time-based tokens can be captured in real-time by phishing sites that perfectly mimic legitimate login pages.
✔️ No Cryptographic Binding: Current methods do not securely tie authentication to the actual domain, leaving room for sophisticated fakes.
The transition to phishing-resistant authenticators is essential.
• FIDO2/WebAuthn Security Keys: Hardware-bound keys like YubiKey and Google Titan offer cryptographically verified authentication that AI cannot replicate.
• Platform Authenticators: Secure access using device-bound biometrics such as Face ID, Touch ID, and Windows Hello.
At Okta, we support teams in making this critical shift by:
👉 Enforcing WebAuthn as a required factor to enhance security.
👉 Utilising Okta FastPass for seamless, device-bound biometric authentication.
👉 Implementing Okta Device Trust to restrict access to managed, compliant devices.
👉 Leveraging Okta Workflows to automate security key enrollment and facilitate adoption.
A phased rollout is vital for success: begin with privileged accounts, progress to high-risk groups like finance and leadership, and then expand universally.
Continuing with legacy MFA increases costs and hinders innovation. It is time to establish phishing-resistant methods as the new standard.
#IdentitySecurity #Okta #PhishingResistance #FIDO2 #WebAuthn #Cybersecurity #IAM
What happens when your security tools become the backdoor?
The era of "trust if inside the network" is behind us. Even our most privileged tools can be exploited as entry points.
This situation underscores the necessity of continuous, context-aware identity verification. For the teams I work with, operational Zero Trust involves:
✔️ Verifying identity every time: Okta’s platform validates users based on behavior and real-time threat analysis.
✔️ Continuously assessing device posture: Ensuring only trusted, healthy devices gain access, which lowers endpoint risk.
✔️ Evaluating context and risk: Google Cloud provides fine-grained access control, enforcing least privilege tied to specific resources and environments.
✔️ Combining identity and infrastructure: Okta manages the "who" and "risk," while Google Cloud controls the "what" and "where," delivering adaptive, resilient security.
My key takeaway: identity has become the last line of defense.
We need a mindset that goes beyond perimeter security—where access relies on trustworthy identity signals closely integrated with infrastructure controls.
If you’re exploring how to better connect identity and infrastructure in your Zero Trust journey, I’m open to connecting and sharing insights.
#ZeroTrust #IdentitySecurity #Okta #GoogleCloud #Cybersecurity #IAM
kubectl apply is too powerful. It’s time to gate your GKE cluster. 🛡️🔐
By default, Kubernetes will happily try to run any container image you throw at it. From any registry. From anyone. In a modern threat landscape, this "trust by default" model is a massive security gap. We need to know cryptographically that the code running in production was built by our trusted CI/CD pipeline, scanned for vulnerabilities, and hasn't been tampered with since.
The solution? Google Cloud Binary Authorisation. It acts as a deploy-time gatekeeper for GKE, rejecting any image that doesn't hold a valid, verifiable "signature" from your trusted build system. I’ve published an implementation guide on securing the software supply chain from Artifact Registry to GKE.
In this article, I cover: ✅ The Trust Chain: Establishing a Root of Trust using Cloud KMS asymmetric keys. ✅ The "Signer": configuring Cloud Build to automatically attest to images post-build. ✅ The Gatekeeper: Writing a GKE admission policy that blocks unsigned images by default. ✅ The "Break Glass": How to bypass controls during emergencies (and audit it instantly).
If SLSA compliance or Supply Chain Security is on your 2026 roadmap, this architecture is the implementation baseline.
Read the full guide here: https://lnkd.in/eA-z5uZw
#GoogleCloud #GKE #Kubernetes #DevSecOps #SupplyChainSecurity #BinaryAuthorization #CloudSecurity #SRE
Interesting news from Google for anyone frustrated with AI coding assistants suggesting deprecated APIs.
We’ve all faced the challenge of spending hours debugging AI-generated code only to realise it’s based on outdated practices.
Google’s Developer Knowledge API, paired with the Model Context Protocol (MCP) server, offers a fresh approach. It connects AI agents directly to official documentation, moving them away from relying on stale training data and toward the current source of truth. This update brings a much-needed real-time information flow to AI coding tools.
For those working at the crossroads of identity and cloud, this matters:
✔️ It helps prevent AI from confidently recommending deprecated APIs, which can save significant time and effort for intricate integrations.
✔️ It strengthens security. An outdated OIDC setup suggested by AI can open up vulnerabilities. Anchoring recommendations in live documentation is essential.
✔️ It provides clarity for complex scenarios like integrating Okta Advanced Server Access with GKE clusters, where having the most precise, up-to-date implementation details is crucial.
The API is still in preview, and its usefulness depends heavily on the quality of the documentation it accesses. While it provides accurate information, applying good architectural judgment remains our responsibility.
Eager to explore this further soon. It would be great to hear how others are approaching AI hallucinations in their workflows.
#GoogleCloud #AI #DeveloperTools #IdentitySecurity #Okta #GCP
What fuels real innovation with AI? It starts with a solid identity foundation.
It's encouraging to see the PGA of America deepening its partnership with Okta and implementing this principle. Instead of adding security later, they have integrated identity management into the core before introducing AI.
Here’s how they are setting up for success:
✔️ A unified platform managing every identity: over 30,000 golf professionals, employees, fans, and importantly, their non-human AI agents.
✔️ Federated authentication providing smooth and secure single sign-on for AI applications.
✔️ Just-in-time (JIT) access granted to AI agents, keeping standing privileges low and reducing risk.
✔️ For those working with GCP, this aligns with leveraging Workload Identity Federation and IAM Conditions for automated, policy-driven access control.
As PGA CTO Kevin J. Scott stated, "Okta's foundation is what allows us to move faster with AI.
This serves as a reminder that strong identity governance isn’t a bottleneck — it’s the foundation needed to innovate effectively and confidently. Ensuring those “agents” are secure from day one opens the door for innovation at scale.
#Okta #IdentitySecurity
This edition covers a breakthrough in Cloud Run cold start performance, the integration of open models directly into BigQuery SQL, and the official launch of the new asia-southeast3 region. Plus, critical updates on Firebase relational support and Service Mesh patching.
RSS feed: https://lnkd.in/e-yRaNQv
#Serverless #CloudRun #GKE #BigQuery #Security
In my work as a technical strategist, I get to bridge two powerful ecosystems: Okta and Google Cloud. It's exciting stuff, but I often see several common gaps when enterprises first integrate them.
Sometimes, teams implement Okta SSO for their SaaS apps and consider the process complete. However, securing your cloud infrastructure demands more attention and planning; it requires an architectural approach rather than simply configuration.
Here are the most frequent identity-cloud gaps I encounter and practical ways to address them:
✔️ Static Service Account Keys vs. Workload Identity Federation Developers often use long-lived GCP service account keys, which pose risks because these credentials are hard to rotate and attribute properly. A better approach is to use Okta OAuth 2.0 tokens exchanged via GCP Workload Identity Pools, allowing for short-lived, automatically rotated credentials.
✔️ The Orphaned Cloud Identity Problem When Okta and Google Cloud Identity each maintain separate user records through dual provisioning, it creates conflicting sources of truth. Users deprovisioned in Okta might still retain GCP access, which risks non-compliance with standards like SOC 2 and ISO 27001. Implementing SCIM provisioning from Okta to Cloud Identity can help automate deprovisioning, ideally within 24 hours.
✔️ Context-Free Authorisation Decisions Relying on basic “yes/no” access based on static roles overlooks critical factors such as device health and user risk. For example, a compromised credential from an unmanaged device currently receives the same permissions as a verified user. This can be mitigated by integrating Okta Risk signals with GCP IAM conditions and VPC Service Controls to enforce adaptive, context-aware access policies.
Effective security should be seamless for legitimate users. Viewing identity as an architectural foundation helps integrate these layers into a cohesive, automated, and more reliable cloud security posture.
If these challenges resonate with you, you’re in good company. Addressing them is a key step toward stronger identity practices.
#Okta #GoogleCloud #IdentitySecurity #WorkloadIdentityFederation #SCIM #ZeroTrust #IAM #CloudSecurity
Google Cloud's 2026 Cybersecurity Forecast reveals significant insights into the intertwining of AI, geopolitics, and technology, highlighting the substantial identity implications.
The concept of “systemic maturity” emphasises the need to treat AI not just as a tool, but as a unique category of identity that requires careful governance.
Key highlights include:
-
The emergence of the “Agentic SOC,” where Security Operations Centers will be bolstered by AI-driven defense mechanisms, while attackers also leverage these capabilities.
-
The rise of "Shadow Agents," a new iteration of "Shadow IT," where unmanaged AI identities within organizations increase the attack surface in ways that must be addressed.
-
The necessity for machine identities, including those driven by AI, to undergo the same lifecycle governance as human users, encompassing provisioning, enforcing least-privilege access, credential rotation, and timely da provisioning.
-
In Google Cloud, this translates to core practices such as securing service accounts, utilising workload identity federation, and maintaining comprehensive audit logs. Collaborating with an identity provider like Okta is crucial for unified governance and ongoing verification.
As autonomous AI continues to grow, continuous trust evaluation must replace one-time authentication. Implementing dynamic least privilege and monitoring agent behavior are now essential steps.
With AI agents gaining more autonomy, it's vital to assess how prepared your identity strategy is to effectively manage these emerging digital identities.
#GoogleCloud #IdentitySecurity #IAM #AI #Okta #Cybersecurity
I’ve been exploring a question with various teams lately: how can you trigger an MFA push notification directly from a line of code?
Managing AI agent identities is becoming an increasingly important focus in cybersecurity. This growing group of non-human identities operates continuously, making thousands of API calls every hour—without an email or a means for traditional MFA.
Traditional IAM tools weren’t designed with this in mind. The challenge is: how do you provision, authenticate, and audit these agents to prevent privilege escalation?
Here’s a practical approach combining Okta and Google Cloud:
✔️ Okta OAuth 2.0 Client Credentials Flow
Leverage programmatic authentication for machine-to-machine communication, enabling AI agents to access APIs securely without relying on long-lived credentials.
✔️ Automated Lifecycle with Okta Workflows
Streamline the agent lifecycle by automating provisioning when deploying new ML models and de provisioning when they’re retired, all while tracking ownership and permissions.
✔️ GCP Service Accounts & Granular IAM Permissions
Apply least-privilege principles with IAM conditions to enforce context-based controls, such as allowing agents to query only BigQuery tables tagged ‘public’ and blocking access to sensitive data.
✔️ Workload Identity Federation to Replace Keys
Replace static service account keys with federated, short-lived credentials from trusted identity providers, reducing attack surface and simplifying audits.
Establishing this foundation provides the visibility and control needed to confidently scale AI deployments with managed identities.
#Okta #GoogleCloud #IdentitySecurity #IAM #AI #CloudSecurity
Is your MFA truly phishing-resistant? 🔐
Our new technical deep dive on Okta FastPass details how Possession-Based Authentication, utilising Cryptographic Binding and Origin Binding, combats AiTM attacks.
Learn about the architectural mechanics, best practices for Global Session and Authentication Policy in OIE, and a strategic framework for a scalable, zero-friction passwordless rollout.
Move beyond legacy MFA. Secure your organisation with device-bound, origin-constrained authentication.
Read the full technical deep dive: https://lnkd.in/eUB2j5bs
#Okta #FastPass #IdentityEngine #Passwordless #MFA #Security #ZeroTrust
According to recent reports from Google Cloud, AI token usage has surged 11 times year-over-year, reaching over 90 trillion tokens processed monthly by the end of 2025. This growth reflects a shift where AI is expanding beyond engineering teams, becoming increasingly relevant to functions like marketing, HR, and finance.
As AI tools like Gemini and Vertex AI become integral to everyday workflows, new security and governance challenges arise:
✔️ Shadow AI: Employees are adopting AI solutions without IT teams being aware, risking data leakage.
✔️ Access Sprawl: The proliferation of AI SaaS apps complicates identity management.
✔️ Data Risk: Sensitive corporate information is entering AI platforms without clear policy guardrails.
✔️ Workflow Redesign: Discussions at Davos emphasized the need to rethink workflows entirely to embed AI safely, moving beyond simple automation.
This is why identity plays a central role. Identity Security Posture Management (ISPM) helps detect shadow AI in real time. Centralized SSO and Okta Workflows enable scalable governance and lifecycle management across these new AI tools.
When we secure the user, we strengthen the foundation for securing AI. A focused identity strategy gives organizations the confidence to innovate responsibly with AI.
I am interested to learn how teams are managing the new governance and access challenges that AI brings. Feel free to share your experiences!
#IdentitySecurity #AI #GoogleCloud #Okta #IAM
This Data Privacy Week, the focus is on protecting people's data, but are we paying enough attention to the machines?
Recent findings in cloud-native AI security highlight a significant blind spot: Non-Human Identities (NHIs). These encompass service accounts, API tokens, and workload identities that drive AI pipelines, often possessing broader access than individual users.
A compromised NHI can stealthily exfiltrate training data, model weights, or inference outputs at scale. Without a "human in the loop," these breaches frequently evade traditional security monitoring.
The challenge is that identity governance often prioritizes humans. While provisioning, access reviews, and deprovisioning are diligently applied to individuals, service accounts can remain active and over-permissioned for extended periods.
On Google Cloud, we can tackle this issue. Workload Identity Federation serves as a crucial first step by eliminating risks associated with long-lived service account keys through the issuance of short-lived, auditable tokens.
When paired with IAM Conditions, it enables the enforcement of granular, least-privilege access by controlling permissions based on factors such as time, location, or workload origin.
Applying the same level of precision and oversight to machine identities as we do for humans is essential for securing AI workflows. Monitoring every NHI’s lifecycle significantly reduces the attack surface.
#DataPrivacy #IdentitySecurity #GoogleCloud #AI #IAM #CloudSecurity #ZeroTrust
An AI model developed by Google's DeepMind has the potential to transform our understanding of DNA, which serves as the complete recipe for building and running the human body. Researchers believe this advancement could significantly impact disease and medicine discovery.
#AlphaGenome #DeepMind
The theme “Take control of your data” resonates strongly with consumers, while for enterprise teams, it’s a matter of designing control through architecture.
Data isn’t protected on its own; strong identity policies make the difference. 🔒
Cloud platforms like Google Cloud offer a secure foundation with encryption, access controls, and audit logs. Identity solutions like Okta serve as the gatekeepers, deciding precisely WHO can access data and under WHAT conditions.
Every access decision then doubles as a privacy decision. Here’s how that plays out:
✔️ Granular controls such as RBAC and ABAC act as privacy filters, enforcing least privilege and reducing data exposure by design.
✔️ Audit trails from identity systems deliver the accountability privacy regulations require, showing exactly who accessed what and when.
✔️ Zero Trust principles bring it all together by assuming no trust by default, helping prevent accidental data leaks right from the start.
Framing your identity strategy as the backbone of privacy shifts how you approach access design, regulatory compliance, and building user trust.
If this sparks ideas for your environment, let’s connect! 🚀
#IdentitySecurity #IAM #Okta #GoogleCloud #ZeroTrust #PrivacyByDesign
Hybrid cloud has become the standard for most enterprises today. However, connecting your legacy data center to Google Cloud requires careful consideration.
Many teams rely on mission-critical database replication over a standard VPN tunnel. While this may function adequately, issues arise when the internet experiences hiccups, leading to packet loss spikes and significant replication lag. The Network Link is a crucial dependency in your hybrid architecture.
I have conducted a technical comparison of HA VPN vs. Cloud Interconnect, covering the following points:
- The Trade-offs: Throughput vs. Cost vs. Setup Time.
- The SLA Math: Understanding why HA VPN requires two tunnels to achieve 99.99% uptime.
- The "Gotcha": Recognising how MTU mismatches (1500 vs. 1460) can lead to silent packet drops.
- The Strategy: Considering the benefits of building both options—using VPN for immediate needs and Interconnect for future scalability.
Don't let a £50 internet glitch compromise your million-dollar architecture.
Read the full guide here: https://lnkd.in/eQVXJvcS
#GoogleCloud #Networking #HybridCloud #CloudInterconnect #VPN #CloudArchitecture #DevOps #SRE
What if your Zero Trust roadmap also served as your best privacy strategy?
As Data Privacy Week 2026 is done (January 26-30), it's an ideal time to discuss security controls in a way that resonates with privacy and legal teams.
The core principles of Zero Trust provide a robust foundation for privacy:
✔️ Verify Explicitly: Clearly identify who accesses personal data and the reasons behind it, establishing accountability and transparency.
✔️ Use Least Privilege Access: Implement purpose limitation by granting only the minimum access necessary for specific tasks.
✔️ Assume Breach: Design systems with the expectation of potential exposure to build resilience and limit impact, thereby protecting data integrity.
In my experience bridging identity (Okta) and cloud infrastructure (GCP), Okta’s continuous verification offers real-time identity trust, while Google Cloud’s audit logging provides the durable evidence that compliance teams rely on.
Presenting our work in this manner transforms challenging cross-team discussions into productive collaborations. It fosters shared clarity that enhances both security and trust.
#ZeroTrust #IdentitySecurity #PrivacyByDesign #Okta #GoogleCloud
What happens to your Google Cloud access the moment an employee leaves? If the answer starts with an IT ticket, you could be facing a serious privacy risk.
Every day an orphaned account remains active increases the chance of unauthorised data access and potential audit issues under regulations like GDPR and CCPA. Manual off boarding, with its delayed tickets and inconsistent steps, creates gaps that attackers and auditors target.
The good news is that Okta Workflows can handle this entire process automatically. You can create flows triggered by user.lifecycle.deactivate events from your HR system (like Workday or BambooHR) that immediately set off a chain reaction:
✔️ Revoke GCP IAM bindings.
✔️ Disable service account keys.
✔️ Remove access to sensitive data in BigQuery.
✔️ Generate a clear, automated audit trail for compliance.
This method shifts your security approach from reactive cleanup to real-time, preventative access control.
If you’re involved in Cloud and IAM automation or looking to improve your offboarding process, feel free to reach out. I’m always up for exchanging ideas.
#IdentitySecurity #OktaWorkflows #GCP
I’ve spent some time reflecting on my Google Cloud Generative AI Leader certification, and three things stand out about the future of AI leadership:
- Strategy over Hype: It’s about solving real business problems, not just deploying chatbots.
- Responsible AI: Governance and ethics must be at the foundation, not an afterthought.
- Ecosystems: Tools like Vertex AI and Gemini are making it easier to scale enterprise-grade AI.
#AIStrategy #VertexAI #GoogleCloud #GenAI #GoogleCloudCertified
Happy to share a focused action for #DataPrivacyWeek: let's audit those Google Cloud service account keys.
It’s common to find keys created for a quick test that remain active with wide access to BigQuery, Cloud Storage, or even AlloyDB. Left unmanaged, these over-privileged keys pose real risks to your data privacy.
Here’s a practical checklist to reclaim control:
- Go to the GCP Console → IAM & Admin → Service Accounts.
- Review each account: Are all its assigned roles truly necessary? Apply the principle of least privilege.
- Check the keys: Are they all still actively used?
- Disable any keys you suspect are unused. If nothing breaks, delete them permanently.
- Rotate any remaining active keys that are older than 90 days.
- Consider whether this use case can be shifted to a more secure, keyless approach like Workload Identity.
Bonus tip: If you use a GCP service account for Okta provisioning, its keys deserve the same careful management. Okta Workflows can help automate reminders and enforce a strict rotation schedule.
Taking charge of your service account keys is essential for a secure, privacy-first cloud environment.
Looking forward to learning how your teams manage key rotation and adopt Workload Identity in production!
Looking for a "keyless" approach? Check out my blog post: https://lnkd.in/e9xWffSS
#GoogleCloud #DataPrivacyWeek #IdentitySecurity #CloudSecurity #Okta #GCP #IAM #AlloyDB #OktaWorkflows #ZeroTrust
The pace of AI agent adoption is nearly ten times faster than the development of governance strategies. The study shows that while the vast majority of organizations—about 91%—are using AI agents, only around 10% have formal strategies in place to manage these non-human identities effectively.
This is a current issue requiring immediate attention.
In cases lacking proper governance, I often see:
💡 AI agents operating with credentials that never get rotated.
💡 Access permissions granted broadly just to ensure things work.
💡 No comprehensive inventory of AI agents or clear offboarding when projects conclude.
These gaps introduce distinct risks—AI agents can become key attack vectors, with breaches occurring at machine speed and evading alerts tuned to human behavior.
Looking ahead to 2026:
- How many AI agents currently have access to your systems?
- What process is in place to offboard AI agents when initiatives end?
- Which role owns governance of AI identities within your organisation?
Moving beyond a human-only IAM focus to managing the full lifecycle of AI agents is an important step forward for security.
I’m interested in hearing how others are approaching AI identity governance and the challenges you’re facing.
If you manage Google Groups, you need to prepare for a significant shift in how Internal vs. External classifications are enforced. Google is officially closing the loopholes that previously allowed external members to exist inside "Internal" groups (via nesting or admin overrides).
Here is the breakdown of what is changing:
🛑 Stricter "Internal" Definition Starting Q2 2026, if a group is set to "Internal," it will be strictly limited to members of your organisation. No exceptions. Admin overrides to add external members? Gone. Nested external groups? Filtered out.
🔄 The Migration Plan To prevent data loss, Google will automatically reclassify any current "Internal" group that contains external members (direct or nested) as "External". This preserves access, but it means your "Internal" groups list might look different overnight.
⚠️ The Critical "Gotcha" for Admins Once this rolls out, if you manually change a group from External to Internal, all direct external members will be permanently removed immediately. Indirect external members (in child groups) will remain in their child group but be "filtered out" of the parent group's communications and permissions.
My Advice: Start auditing your group structures now. Look for nested groups that might have hidden external members. Decide now which groups should truly be Internal and which need to remain External, rather than waiting for the auto-classification to decide for you.
🔗 Read the full support article here: https://lnkd.in/eKzMBwTm
#GoogleWorkspace #ITAdmin #CyberSecurity #GoogleGroups #TechNews #CloudSecurity
Managing identity across Google Cloud, AWS, and Azure often creates separate IAM silos—a recipe for permission sprawl and audit nightmares.
When identity management isn’t unified, it leads to operational challenges and leaves gaps that put security at risk.
A better approach is to centralise identity as your control plane to scale a true Zero Trust posture.
👉 Bring identity together with Okta. This helps your team apply consistent policies across all cloud environments, moving from firefighting isolated settings to focusing on strategic improvements.
👉 Use Okta Workflows to take on the repetitive tasks. You can automate access reviews, deprovisioning, and policy enforcement across clouds without complex coding.
👉 Take advantage of Google Cloud IAM Conditions for just-in-time access. Attribute-based controls and time-bound credentials enable least-privilege access and reduce exposure.
👉 Remove standing privileges with automation! Most accounts don’t require constant access to production, so automating this step strengthens security hygiene significantly.
Silos across cloud platforms hinder your Zero Trust efforts. Making identity the central control point lets you build a reliable security posture that scales efficiently. This shift turns routine cleanup into purposeful automation! 🚀
If you want to see how IAM conditions or automation can fit into your environment, I’d be happy to share insights.
#IdentitySecurity #Okta #GoogleCloud #ZeroTrust #IAM #CloudSecurity #OktaWorkflows
Exciting news from Google Cloud! 🚀 They've just updated their partner program in a way that really opens the door for specialists to shine.
Starting January 15, 2026, the broad "specialisations" were replaced with 21 focused competencies. This approach prioritises documented expertise and results over just partner size.
Here’s how it breaks down:
✔️ Proven Expertise: These competencies reflect both capacity (through certifications) and capability (validated by customer success stories). It’s about real achievements rather than branding alone.
✔️ Level Ground: Smaller, focused teams now compete directly with large global SIs. As Onix CEO Sanjay Singh highlights, this brings more balance and opportunity for specialists.
✔️ Clear Signals: In identity and cloud infrastructure, competencies like Security, Databases (including AlloyDB), and DevOps help simplify finding the right partner with the right skills.
✔️ Worldwide Reach: Competencies apply globally, removing regional barriers and making it easier for customers anywhere to identify the best partners.
For customers, this means your next identity or database project can find a partner with the right proven competency, not only the largest name. For practitioners, it’s an important nod to the value of deep expertise. Specialisation is a powerful differentiator.
It’s great to see the ecosystem evolving to recognise authentic, validated skills!
#GoogleCloud #IdentitySecurity #CloudArchitecture #PartnerEcosystem
The most dangerous file on your laptop? It’s probably that service-account.json key. 🔑⚠️
We have all done it. You need your GKE Pod or local script to access a Cloud Storage bucket, so you generate a Service Account Key, download the JSON, and mount it as a secret. It works, but it’s a ticking time bomb.
Long-lived JSON keys are the #1 vector for cloud compromises. They don't expire, they get accidentally committed to git, and rotating them is a nightmare. It’s time to go Keyless.
I just published a new deep-dive technical guide on lineargs.dev about implementing Workload Identity—the "Zero Trust" standard for modern Google Cloud authentication.
In this guide, I break down: ✅ The Architecture: How Identity Federation allows Kubernetes Service Accounts to "masquerade" as Google Service Accounts. ✅ The Implementation: A complete gcloud and kubectl walkthrough to set up the binding correctly (and avoid common permission errors). ✅ The Debugging: Understanding the "invisible handshake" between the Pod and the GKE Metadata Server. ✅ The Result: No more JSON files. Just short-lived, auto-rotated tokens managed by Google.
If you are still mounting secrets for IAM access, this guide is your blueprint to modernisation.
👉🏼 Read the full guide here: https://lnkd.in/ekFirpsX
#GoogleCloud #GKE #Kubernetes #CloudSecurity #DevSecOps #WorkloadIdentity #ZeroTrust #CloudArchitecture
Building the Future of EdTech with GenAI and Cloud Run ☁️🎮
Sharing my latest project, The Serverless Survivor—a retro-style survival game that challenges your Google Cloud knowledge. While it looks like an 8-bit arcade game, the backend is a modern study in serverless efficiency.
The Tech Stack: 🚀 Compute: Next.js on Cloud Run (via Firebase App Hosting) for auto-scaling and 0 idle costs. 🧠 Brain: Vertex AI (Gemini) generates unique survival scenarios, ensuring the content is never stale. 🔥 Data: Cloud Firestore for real-time leaderboards and content delivery.
This project demonstrates how to decouple content generation from application logic. The game acts as a "consumer," while Gemini acts as the "creator," autonomously populating the database with new levels.
Check out the code or try to survive the jungle below! ▶️ Play here: https://lnkd.in/eNu4kbbj 💻 GitHub: https://lnkd.in/e2G7JYY2
#GoogleCloud #Serverless #CloudRun #VertexAI #GenAI #NextJS #Firebase #OpenSource
Automation and orchestration are now a key element of Zero Trust security.
The recent guidance for Operational Technology (OT) establishes this as a strategic priority, encouraging a move away from manual, fragile workflows toward systems that handle scale, failures, and evolving threats with greater resilience.
In the workshops and deep dives I lead, a few essential principles for creating dependable automation workflows consistently come up:
✔️ Design for failure — Treat every external API call as a potential point of failure. Incorporate error handling and retry mechanisms to manage rate limits and outages effectively.
✔️ Avoid monolithic workflows — Break complex tasks into smaller, reusable “helper flows” to simplify testing, troubleshooting, and maintenance.
✔️ Use tables for state management — For large-scale operations like syncing thousands of users, maintain progress within persistent tables. This approach allows smooth recovery and continuation after interruptions.
✔️ Build in logging and monitoring from day one — Visibility is crucial. Collect detailed execution logs to quickly identify failures and security incidents.
✔️ Test at production scale — Run your automation against real-world volumes, not just small sandbox data sets, to uncover hidden issues before going live.
These practices matter because critical use cases like automated identity lifecycle management, prompt session revocation on risk signals, and consistent provisioning across systems all depend on automation that supports effective governance at scale.
If it’s been a while since you last reviewed your key workflows, now’s a good opportunity. Consider how your automation deals with failure: Does it recover smoothly? Is it built to be modular and transparent? That’s what true governance at scale requires. 🚀
Let’s connect and share insights on automation and Zero Trust!
#Okta #IdentitySecurity #ZeroTrust #Automation #CloudSecurity #OperationalTechnology
The AI landscape is evolving beyond just chatbots. 🚀
Google Cloud’s Gemini Enterprise for Customer Experience is a notable example. AI agents can now book appointments, handle returns, and process transactions by connecting directly to customer data and backend systems.
This introduces significant identity challenges.
Leaders have raised concerns about "shadow agents"—AI systems created by various departments without IT oversight, often granted excessive privileges.
Traditional IAM tools struggle here. These non-human identities rely on API keys or service accounts that often aren’t rotated or expired, sidestepping regular governance controls.
Addressing this calls for a dedicated framework focused on lifecycle management, enforcing least privilege, and continuous access reviews.
For IAM professionals and cloud architects, it’s crucial to start identifying and managing these AI agents proactively to avoid audit risks.
What approaches is your organisation taking to treat AI agents as first-class identities? I’d be glad to share insights and hear your experiences.
Here’s a quick tip for managing Okta Verify updates on Windows without sacrificing stability. 💡
While Okta Verify’s automatic updates are essential for security, we all know that a surprise update can sometimes disrupt carefully managed enterprise environments.
The good news is you have more control than you might think! Okta uses a staggered 7-day rollout for new versions (starting at 5% of devices and scaling to 100%), which provides a natural safety buffer.
You can improve your approach by deferring these updates strategically to build in a testing window. Instead of disabling updates (which poses risks), use the built-in AutoUpdateDeferredByDays setting.
Here’s the approach:
🚀 For new installations: Deploy Okta Verify with AutoUpdateDeferredByDays set to a value between 1 and 13. This delays the update for that many days after the main 7-day rollout is complete.
🔧 For existing installations: You can update the registry on devices using a simple PowerShell command to set the deferral period. Just remember to restart the Okta Verify app for the change to take effect.
For pilot groups, it’s worth enrolling your IT team or a small test group into the Early Access (Beta) program using the EnrollInBetaProgram option. This way, they get early access to releases while the rest of the organisation remains on a deferred update schedule.
This approach helps validate updates, confirm compatibility, and maintain stability without compromising security.
If you’re managing Okta Verify in your environment, I’m happy to connect if you’d like to talk PowerShell scripts or beta program strategy!
#Okta #IdentitySecurity #Windows #ITAdmins #PowerShell #ZeroTrust #OktaLife
Recently, I’ve been exploring QUIC, the transport layer protocol behind HTTP/3.
Originally developed at Google and now an IETF standard (RFC 9000), it moves away from the traditional TCP handshake bottleneck, integrating security and speed from the start.
Here are a few key points:
✔️ Zero Round-Trip Time (0-RTT): QUIC reduces initial latency by sending encrypted data immediately, removing handshake delays.
✔️ Smarter Streams: Unlike TCP, a stalled packet doesn’t block everything else. This improves throughput and smooths out complex app performance.
✔️ Built-in TLS 1.3: Encryption is baked into the protocol, supporting an identity-first security posture directly at the transport layer.
✔️ Seamless Connection Migration: QUIC maintains connections as users switch networks (e.g., from Wi-Fi to 5G), enhancing mobile experience.
For those working with Google Cloud, it's worth reviewing Load Balancer and CDN settings to make sure you’re taking advantage of what HTTP/3 offers. This isn’t just a simple protocol update — it supports faster, more secure, and more reliable user experiences.
If you’ve started using HTTP/3 or experimenting with QUIC, I’d love to hear how it’s impacting your setups.
#GoogleCloud #CloudArchitecture #HTTP3 #QUIC #SecurityByDesign #NetworkPerformance #IdentitySecurity
The 2026 cybersecurity predictions are in, and the consensus is clear: AI plays a central role in both cyber attacks and defense.
A key change is that AI agents have evolved beyond being mere tools; they now act as digital identities that need their own governance. Attackers move past just breaching servers—they are logging in, often using these autonomous AI identities.
It's encouraging to see the industry already addressing this challenge. Here are some important points from recent reports and announcements:
✔️ Identity is becoming the new perimeter. AI is driving more advanced credential theft and large-scale automated social engineering.
✔️ Non-human identities need governance. The rise of "agentic AI" requires each autonomous system to have access controls to prevent overprivileged "shadow agents.
✔️ Okta introduced new AI agent security features, indicating clear progress toward managing and governing these identities.
✔️ On the infrastructure side, Google's recently announced Private AI Compute enables running powerful AI models while protecting data inside hardware-enforced enclaves.
To fully realise AI's benefits in the cloud, an identity-first security approach that covers human and AI-driven identities is essential. This focus perfectly aligns with my passion—connecting identity governance from Okta.
If your team is exploring AI identity management or looking for best practices, feel free to reach out. I'm always glad to connect and discuss what's coming next!
#IdentitySecurity #AI #Cybersecurity #Okta #GoogleCloud #IAM #ZeroTrust #GoogleCloudSecurity #CloudSecurity #NonHumanIdentity
Interesting developments in AI security!
Google Cloud’s GKE Agent Sandbox (which uses gVisor) offers robust infrastructure security through kernel-level isolation. On top of that, Palo Alto Networks complements this with Prisma AIRS, providing platform-level AI threat detection.
Together, these solutions cover where AI runs and what security policies monitor.
This brings up important identity questions:
- Who is responsible for granting an AI agent its initial privileges?
- How do you maintain least privilege for an agent that can learn and evolve?
- What is the process for revoking access when an agent is retired?
- How can you verify what actions the agent performed versus what was intended by humans?
Without clear identity governance, you risk having secure but invisible “ghosts” inside your infrastructure.
Identity and platform teams must work closely together. For instance, Okta Workflows can help automate the lifecycle of service principals tied to AI agent deployment and retirement, ensuring least privilege access and clean deprovisioning every time.
Securing AI requires integrating identity governance from the start. The question of “who” can no longer be overlooked.
#GoogleCloud #IdentitySecurity #Okta #GKE #AI #Cybersecurity #IAM #ZeroTrust
Serverless is a game-changer for speed, but for those in regulated industries (Finance, Healthcare, Public Sector), the default behaviour of Cloud Run (public URLs for everything) is often a non-starter.
Historically, solving this meant complex VPNs or messy VPC peering. But there is a better, modern architectural pattern: Private Service Connect (PSC).
I just published a deep-dive technical guide on lineargs.dev exploring how to architect a "Zero Trust" serverless environment.
In this article, I cover: ✅ The Architecture: How to keep your traffic "dark" to the public internet using Internal Load Balancers and Serverless NEGs. ✅ The "How-To": A step-by-step implementation guide (gcloud commands included). ✅ The "Gotchas": Solving the DNS resolution headaches and SSL certificate management. ✅ The Networking: Bypassing CIDR overlaps and securing cross-project boundaries.
If you are modernising legacy workloads but stuck on security compliance, this architecture is your bridge.
👉🏼Read the full deep dive here: https://lnkd.in/edqpfa28
#GoogleCloud #CloudRun #Serverless #CyberSecurity #CloudArchitecture #DevOps #PrivateServiceConnect #Networking
Only 33% of security leaders are confident their current identity provider can stop identity-based attacks.
This gap in confidence reflects what I observe regularly: teams face significant challenges as identities multiply and AI-driven threats grow.
Duo’s 2025 Identity Security Trends report highlights key numbers behind these challenges:
✔️ 94% of leaders agree that the growing complexity of their identity infrastructure actually reduces overall security.
✔️ 75% acknowledge they don’t have complete visibility into identity vulnerabilities across their organisations.
✔️ 87% see phishing-resistant MFA as essential, yet only 30% feel very confident about their phishing defenses.
✔️ 61% want to move towards passwordless access but expect to encounter implementation hurdles.
✔️ 86% are concerned about insufficient controls over contractor and third-party access.
These figures make it clear why prioritising a security-first IAM approach is critical. Treating identity security as a core foundation—not an afterthought—is the best way to close the gaps attackers seek to exploit.
If your AI agent connects to Gmail, GitHub, or Slack, it's a privileged user with powerful access.
Attackers are increasingly targeting this "connective tissue" of identity and access, not the AI models themselves. We've seen over 91,000 malicious sessions targeting AI infrastructure since October 2025 (Cyberpress), while other attackers are abusing Google Cloud email features to bypass traditional phishing defenses (The Hacker News).
For identity and access management, this requires a clear plan:
✔️ Identity Lifecycle Management: Just like human employees, AI agents require strict onboarding, regular permission reviews, and timely offboarding. Long-lived OAuth tokens are a major risk if left unchecked.
✔️ Least Privilege Access: It's crucial to evaluate every OAuth scope assigned to an AI tool. Ask, “Does this agent really need write access?” Minimising permissions reduces the potential blast radius.
✔️ Continuous Access Evaluation (CAE): Static, one-time approval for an AI agent is no longer enough. Access should be reassessed dynamically in real time to catch malicious activity happening at machine speed.
✔️ Comprehensive Audit Trails: We need full visibility into AI agent API calls. Every integration should generate detailed logs to enable effective forensics and anomaly detection.
Breaches involving AI agents can escalate in milliseconds. This makes applying Zero Trust principles to machine identities more important than ever, extending identity-centric controls to them with the same rigor as we do for human users.
Managing the identity lifecycle and access boundaries for AI agents is becoming increasingly essential across organisations.
#IdentitySecurity #ZeroTrust #AI #IAM #CloudSecurity
Following the latest Google Cloud release notes (https://lnkd.in/e33FDsED), I've been diving into recent updates across Compute, Data, AI, and Security.
Here are a few highlights from that caught my attention:
✔️ GKE Kubernetes 1.35: Now available in the Rapid channel, bringing the latest upstream features to container orchestration. Note that cgroup v1 support has been removed in this version—something to watch if you're managing legacy workloads.
✔️ Cloud Run Java 25: The newest Java runtime is now Generally Available, keeping serverless deployments current with the latest language features.
✔️ BigQuery Iceberg Tables: Preview support for transferring data from Amazon S3, Azure Blob Storage, and Cloud Storage directly into BigLake Iceberg tables—a major step for open lakehouse architectures and multi-cloud data strategies.
✔️ Imperva WAF for Google Cloud: A cloud-native offering that inspects traffic directly within GCP using Service Traffic Extension and Private Service Connect. This aligns perfectly with an identity-first security posture.
✔️ Security Command Center Premium Pay-As-You-Go: Advanced AI, data security, and compliance monitoring features are now available to more customers—democratising access to enterprise-grade security tooling.
For those working with Google Cloud, staying on top of these updates ensures you're taking advantage of the latest performance, security, and integration capabilities. I'm particularly excited about the BigQuery Iceberg support for its impact on data portability and the new WAF integration for tightening security at the network edge.
If you've implemented any of these features or have insights on the roadmap, I'd love to hear how they're impacting your architecture. Let's connect and explore together!
#GoogleCloud #CloudArchitecture #GKE #BigQuery #SecurityByDesign #CloudSecurity #IdentitySecurity