Identity and Access Governance (IGA): Definition & Differentiation Explained

Identity is now the most common entry point for attackers. In cloud-native environments, thousands of microservices, containers, and agents request credentials every day, and each one represents a potential weakness. The imbalance between human and non-human identities (NHIs) is growing, but many organizations still devote the bulk of their identity and access governance (IGA) efforts to the former.

Over the past two years, 57% of organizations experienced at least one API-related breach; of those, 73% saw three or more incidents. At the same time, the global IAG market was valued at approximately $8 billion in 2024, driven by compliance frameworks such as SOC 2, GDPR, HIPAA, and CCPA that demand auditable proof of access controls.

The takeaway: static defenses built on logins and standing permissions can’t keep pace with identities that appear and disappear daily. For engineering teams, identity and access governance has shifted from a “nice-to-have” to a baseline requirement for both security and trust.

What is identity and access governance (IGA)?

Identity and access governance (IGA) is the framework your organization can use to decide who should have access to systems, applications, and data, and whether that access is still appropriate. IGA goes beyond the mechanics of logging and instead focuses on oversight, accountability, and policy enforcement.

Most IGA programs are built around a few core practices:

Identity lifecycle management: Provisioning, modifying, and deprovisioning accounts.
Role and entitlement management: Grouping permissions and enforcing least privilege.
Access reviews and certifications: Recurring checks to validate appropriateness of access.
Compliance reporting: Generating evidence required by auditors and regulators.

Unlike identity and access management (IAM), which enforces access at runtime, IGA asks the harder question: should this access exist at all? Answering this question is harder today because identities are multiplying. Machine identities outnumber humans by over 80 to 1, making them one of the fastest-growing risk classes in cloud-native environments. Unlike human accounts, NHIs rarely go through onboarding or offboarding, rely on static API keys or long-lived tokens, and are frequently overprivileged—the perfect storm for attackers.

Source

Core capabilities of Identity and Access Governance

IGA is about ensuring access is both appropriate, accountable, and, most importantly, auditable. To achieve these three pillars, IGA platforms bring together several capabilities.

Access reviews and certification: Periodic checks give managers and system owners the chance to confirm that permissions are still valid. They’re meant to clean up access left behind after job changes, project work, or employee turnover.

Role and entitlement management: Permissions are grouped into roles to make administration manageable. This model keeps access consistent across teams and reduces the scatter of exceptions that creep in over time.

Separation of Duties (SoD): SoD prevents conflicting privileges so that no single identity has the ability to commit fraud or bypass checks.

Audit and compliance reporting: Most frameworks, from SOC 2 to GDPR, require proof that access is being governed. Automated reports provide that evidence and complement broader vulnerability management programs designed to reduce risk.

Delegated administration and approval workflows: Requests can be routed to business or technical owners who best understand whether access makes sense. This step spreads responsibility more evenly, while decisions remain logged centrally.

Crucially, modern IGA extends these capabilities beyond human users to include NHIs, ensuring service accounts and automation agents undergo the same scrutiny as employees.

Source

IGA, IAM, and PAM Compared

Identity management has grown into a set of overlapping disciplines, each with its own focus. Many people still use the terms interchangeably, but this approach can blur the lines between strategic governance and privileged account protection.

It’s helpful to understand exactly where each begins and ends. IAM is concerned with authentication and access control at the point of login. IGA adds oversight, certification, and auditability across all identities. To monitor and control their activity, privileged access management (PAM) narrows in on the riskiest accounts, such as administrators and root users. For example, organizations rely on PAM software to enforce controls around these sensitive accounts, ensuring that high-risk permissions are granted only when necessary and closely monitored.

Table 1: IGA vs IAM vs PAM

Discipline	Focus	Typical Scope	Key Purpose
IAM	Enforcement	Authentication, MFA, SSO	Prove identity and control access at login
IGA	Governance	Human and non-human identities	Define, review, and certify who should have access and why
PAM	Privilege	High-risk administrator and root accounts	Control and monitor privileged sessions

5 Challenges of Implementing IGA in Cloud-Native Environments

1. Scaling Ephemeral Identities

In a cloud-native stack, thousands of containers, pods, and serverless functions may launch and terminate within minutes. Each instance often requires its own token or temporary credential to function. Legacy governance processes that rely on quarterly or monthly reviews cannot track this churn, so permissions are left unchecked. Security teams end up with audit trails that miss most of the short-lived identities, which makes proving compliance or investigating incidents almost impossible. A best practice to overcome this challenge is to use a cloud-native access management solution like Apono, which automates JIT access and generates granular audit logs, so even short-lived identities are governed in real time.

2. Complex Permissions

Cloud providers like AWS, Azure, and GCP offer permission systems with thousands of individual actions that can be combined into highly customized roles. Developers frequently over-provision roles because mapping business tasks to such granular entitlements is too time-consuming. Over time, these permission sprawl problems multiply, creating toxic combinations that static governance models don’t properly evaluate.

3. Friction with Development Teams

When engineers need access to a production database or a new cloud service, the request usually goes into a ticket queue. When reviews take too long, teams are forced to delay work or find workarounds such as borrowing credentials.

This bottleneck not only slows delivery but also weakens governance because security becomes seen as a blocker rather than a partner. In some organizations, administrators pre-approve broad entitlements “just in case.” This mistake undermines the entire principle of least privilege and increases the chance of compromised credentials being abused across environments.

4. Non-Human Identities

Source

Unmonitored NHIs are among the most consistent attack vectors in identity-driven breaches today. Service accounts and automation agents run critical workflows in CI/CD pipelines, monitoring systems, and infrastructure tools. These identities often carry long-lived credentials with powerful permissions. Unlike human users, they rarely leave the organization, so deprovisioning processes don’t catch them.

When one of these accounts is forgotten or left unmonitored, it becomes a permanent backdoor. Attackers frequently target exposed API keys or tokens for this reason, knowing they are less likely to be rotated or reviewed. As we’ve seen with emerging issues like the MCP protocol, unsecured machine-to-machine communications can further amplify the risks of unmanaged NHIs.

Recent examples include Microsoft’s 2023 SAS Token Leak, where researchers inadvertently published a token that exposed 38TB of internal data, and the BeyondTrust API Key Breach in 2024, where attackers exploited an overprivileged, static key to reset passwords and escalate privileges. Both incidents highlight how unmanaged non-human identities can open the door to large-scale compromise.

An essential NHI security best practice is to run a Cloud Access Assessment to uncover risks in your AWS environment, provided by Apono at no cost (for a limited time only). Apono’s platform is built to close this blind spot by enforcing JIT and JEP policies for NHIs just like human accounts, stopping long-lived keys from becoming backdoors.

5. Fragmented Visibility

Most enterprises work across multiple clouds, each with its own identity console and reporting format. Security teams trying to answer “who can access sensitive data” are forced to stitch together incomplete reports. The lack of a unified view leaves gaps for auditors and prevents real-time oversight—a challenge that becomes even more critical in industries like FinTech or government, which are subject to additional compliance requirements like CUI Basic.

How Modern IGA is Evolving

Identity governance is moving from periodic checks to continuous oversight. Instead of leaving broad permissions in place and revisiting them months later, newer approaches shift towards:

Just-in-Time access (JIT): Temporary access that expires automatically and reduces the window of risk while giving auditors a clearer picture of how access is actually being used. JIT access automation and contextual approval workflows are essential for scaling governance without undermining developer productivity.
Zero Trust: Assumes no identity should have standing access by default. Every request must be verified in context, regardless of whether it comes from a human developer or a bot in a CI/CD pipeline.
Just-Enough Privileges (JEP): JEP is particularly important for NHIs. JEP grants the minimum rights needed for a task for the shortest possible time. This shift addresses the chronic overprovisioning of machine identities, aligns with Zero Trust, and directly reduces the blast radius of a potential compromise.
Workflow integration: Approvals embedded into Slack, Teams, or CLI so governance fits into daily developer workflows.

By enforcing just-in-time access and contextual approvals, IGA reduces the standing permissions that often undermine API security in CI/CD pipelines and cloud workloads.

Bringing Automation to the Center of Governance with Apono

Cloud-native deployments and the explosion of non-human identities have pushed traditional identity governance past its limits. Static reviews and manual approvals leave too much standing access in environments where roles and permissions change constantly. To reduce risk, governance needs automation, time-bound access, and policies that apply equally to people and non-human accounts.

Apono redefines IGA for cloud-native teams. It eliminates risky standing permissions for both human and non-human identities, while ensuring compliance frameworks increasingly require full visibility into NHI governance. Apono’s platform automates JIT and JEP to eliminate standing permissions, generates granular audit logs for compliance, and applies governance equally to human and non-human identities. Approvals flow directly through Slack, Teams, or CLI—every action logged, every change auditable.

With built-in break-glass and on-call flows, and deployment in under 15 minutes, Apono delivers Zero Trust governance at the speed of modern infrastructure.

Ready to Eliminate Standing Access Risk?

Apono closes the gap by automating JIT and JEP for both human and non-human identities — stopping long-lived keys from becoming backdoors.Download The Security Leader’s Guide to Eliminating Standing Access Risk to see how leading cybersecurity companies are rethinking access control.

Inside the Crimson Collective Attack Chain—and How to Break It with Zero Standing Privileges

New details are emerging in recent weeks on how the Crimson Collective threat group has been conducting a large-scale campaign targeting Amazon Web Services cloud environments. Recent reports highlight how easily the attackers progressed once they obtained valid credentials.

The Crimson Collective claims to have exfiltrated ~570 GB across ~28,000 internal GitLab projects; Red Hat has confirmed access to a Consulting GitLab instance but hasn’t verified the full scope of those claims.

After the breach became public, Bleeping Computer reports that the threat actors partnered with headline-grabbing extortion group, Scattered Lapsus$ Hunters, to increase pressure on Red Hat.

In this post, we’ll break down how the hackers carried out their attack and how to keep your organization protected via a Zero Standing Privileges approach.

Breaking Down the Attackers’ Methodology

According to the report from Rapid 7 in Bleeping Computer, the attackers took a tried but true course of action to compromise their targets and make off with their illicitly obtained data.

Find exposed keys — They used TruffleHog to scan target environments and discover secrets in repos, configs, or other leaks to gain initial access.
Establish persistence — Then they used the leaked keys to call AWS APIs and create highly privileged IAM users/login profiles and new access keys.
Privilege escalation — With their foot firmly in the door, they attached AdministratorAccess to their new users. Boom: full control.
Recon — Privileges in hand, they then hit the cloud running, enumerating users, EC2, S3 buckets, RDS clusters, EBS volumes, regions, and apps to map the prize.
Data collection — Next they started hoovering up data, changing RDS master passwords, taking snapshots of their targets’ DBs and EBS volumes.
Exfiltration — With the targets’ data collected, they moved the snapshots/objects to S3 buckets that they controlled or accessible storage; using EC2s that they spun up and attaching volumes under permissive security groups for faster transfers.
Extortion — Finally, they sent ransom notes from inside the AWS account using SES and to external contacts.

The Cloud Identity Challenge

This latest attack highlights a tough if not cliche truth in the cloud: attackers don’t need to break in if they can just log in. Once credentials with standing privileges are compromised, it gives them everything they need to move freely across environments.

The reality is that credential compromise is now a matter of when, not if. And as the number of Non-Human Identities (NHIs)—like service accounts, IAM roles, and API keys—continues to explode, the challenge keeps growing. In many organizations, NHIs now outnumber human users by roughly 200 to 1.

Things are getting even more complicated with the rise of Agentic AI tools. These systems operate at massive scale with unpredictable access needs, often without the visibility security teams rely on to monitor what’s actually being accessed.

Protecting against these kinds of attacks means focusing not just on preventing credential theft, but on minimizing what attackers can do after credentials are compromised. That’s why AWS told BleepingComputer that customers should “use short-term, least-privileged credentials and implement restrictive IAM policies.”

That advice perfectly captures the idea behind Zero Standing Privileges (ZSP), reducing the amount of always-on access available in your environment, so even if credentials are stolen, attackers have nowhere to go.

Of course, actually putting that into practice is the hard part. Manual access management is slow and painful, and cutting privileges too aggressively risks hurting productivity. And as cloud environments and NHIs multiply, keeping up manually just isn’t realistic anymore.

How Apono Helps

Apono makes it simple to put Zero Standing Privileges into action—without slowing anyone down.

Here’s how:

Automatically discovers and remediates standing privileges across both human and non-human identities
Delivers Just-in-Time (JIT) access, granting permissions only when needed and revoking them immediately after use
Reduces Non-Human Identity (NHI) privileges safely, using automated rightsizing via quarantining and reversible remediation that preserves uptime and avoids breaking integrations
Centralizes and automates governance, unifying policies across cloud, on-prem, and AI-driven systems
Supports Zero Trust initiatives, enforcing short-lived, least-privileged access without adding friction for engineers

With Apono, security teams can close privilege gaps before attackers can exploit them, while developers and AI systems get access exactly when—and only when—they need it.

If you want a quick way to benchmark where standing privileges still exist in your environment, download our Zero Standing Privileges (ZSP) Checklist: a fast, practical self-assessment to help you identify hidden risks and early indicators of exposure.

Ready to take a smarter approach to cloud access?

See how Apono can help your organization prevent credential-based attacks while keeping teams fast and productive. Visit apono.io/jit-and-jep/ to learn more about our platform or request a demo.

What is Agent2Agent (A2A) Protocol and How to Adopt it?

Imagine autonomous agents negotiating and acting on your behalf—no manual hand-offs, just an efficient, policy‑driven communication. That’s the promise of Google’s Agent2Agent (A2A) Protocol, unveiled at Google Cloud Next in April 2025. Developed with input from over 50 partners, A2A is now open-sourced under the Apache 2.0 license and governed by the Linux Foundation.

But excitement quickly collides with reality. Early adopters report compliance blind spots (who approved that token and when?), latency added by cross-agent orchestration, and the operational overhead of adding another standard into pipelines. As agent-based architectures become the backbone of AI-driven automation, the pressure is mounting on engineering teams to enable secure, autonomous interactions between services.

A 2025 global AI survey reveals that 29% of enterprises are already running agentic AI in production, with another 44% planning to join them within a year. Cost-cutting and reducing manual workloads are among the top goals for adoption. Understanding the Agent2Agent Protocol is vital for building secure and scalable systems that can keep up with the next wave of automation.

What is the Agent2Agent (A2A) Protocol?

Google’s Agent-to-Agent (A2A) Protocol is an open, vendor-neutral language that lets independent AI agents discover each other, negotiate how they will talk (text, files, streams), and work together without exposing their private code or data.

Google unveiled the spec on April 9, 2025, at Cloud Next. It is backed by more than 50 technology partners and is now maintained as an open-source project under the Apache 2.0 license.

Google kicked the A2A project off after running large, multi-agent systems for customers and seeing the same pain points repeat:

Brittle one-off integrations.
Security gaps.
No common way for agents from different vendors to “shake hands.”

How does the Agent2Agent Protocol work?

The four-step flow below illustrates the full A2A handshake from discovery to streaming task updates.

1. Discovery with an Agent Card

Every agent publishes a tiny JSON file, /.well-known/agent.json, listing its name, endpoint, skills, and supported auth flows. A client agent simply fetches this card (directly or via a registry) to see who can do what and how to connect.

2. Auth in Micro-slices

The card also tells the caller which OAuth 2/OIDC method to use. The client obtains a short-lived token (minutes), allowing access to be scoped and automatically expires. This step eliminates hardcoded secrets, marking a shift from static secrets to dynamic machine identity management, where each agent authenticates based on policy, context, and lifespan.

3. Task Exchange Over Web Standards

With a token in hand, the client sends a task/send or task/sendSubscribe request via JSON-RPC 2.0 over HTTPS.

Synchronous work:task/send returns the answer right away.
Long-running work:task/sendSubscribe opens a Server-Sent Events (SSE) stream so the remote agent can push status and partial results. Tasks move through states (submitted → working → completed) and can include messages or artifacts (files, JSON blobs, images).

4. Built-in Observability

Each request/response carries trace IDs, and agents emit structured logs and metrics in OpenTelemetry Protocol (OTLP) format. You can drop A2A traffic straight into existing dashboards without bolting on a separate telemetry layer. This level of observability is essential for identifying anomalies and containing the risks of non-human identities operating in complex, distributed environments.

Many teams adopting A2A have struggled with blind spots, like losing track of which agents initiated sensitive operations or where tokens are reused across flows. Without built-in tracing and structured logs, auditing multi-agent systems becomes a fragmented, manual task. A2A’s observability layer helps reduce that operational burden, but it still requires thoughtful integration with existing security tooling.

What is the Agent2Agent Protocol designed to do?

At its core, A2A gives every software agent a common language and contract so they can:

Discover one another without manual registry updates.
Exchange tasks securely with scoped tokens and auditable IDs.
Stream real-time results (via SSE) from remote agents for both quick jobs and long-running workflows.

By replacing brittle webhooks and custom RPC layers with an open JSON-RPC spec, the Agent2Agent Protocol eliminates glue code and reduces integration overhead across ecosystems.

Because discovery, auth, transport, and telemetry are part of the spec, you don’t waste cycles reinventing service discovery, API gateways, or audit pipelines. You wire agents together (much like microservices), then layer governance tools on top to enforce least-privilege, time-boxed access across your infra. It reduces repetitive integration tasks, which improves developer productivity across teams working in complex environments.

Why is the Agent2Agent Protocol a good thing?

The Agent2Agent Protocol solves real pain points in DevOps and automation by making agent communication smarter and safer. Here’s why it’ll be beneficial in the long run.

Plug-and-Play Interoperability

Any AI agent that speaks A2A can call, or be called by, any other agent.

Example: If a vulnerability scanner agent discovers a patch management agent during a CI run, it can send a task with the CVE list and stream the fix status back to the build.

Built-in Security

Short-lived OAuth/OIDC tokens and signed task IDs keep access scoped and auditable without requiring the hardcoding of secrets.

Example: When a monitoring bot detects a spike, it requests a one-off token to spin up extra pods. The token expires automatically once scaling is complete, aligning with enterprise identity management best practices.

Less Glue Code, Faster Pipelines

The Agent2Agent Protocol includes built-in support for agent discovery, JSON-RPC 2.0 transport, and SSE streaming. Teams can focus on features instead of writing adapters and polling loops.

Example: A scheduler agent queries rightsizing agents in AWS, GCP, and Azure, aggregates savings, and opens a single cost-cutting PR. No polling scripts are required.

Enterprise-Grade Observability

Every request carries trace IDs and standard OTLP metrics, which are dropped straight into Grafana/Prometheus dashboards, regardless of whether those agents are operating in the cloud, across edge services, or in traditional data centers.

Example: A chatbot passes a billing request to a payment agent via A2A; the handoff is fully logged, and the one-time token expires as soon as the charge is completed.

Agent2Agent Protocol Design Principles

These guiding principles explain why A2A stays flexible, secure, and developer-friendly as the ecosystem expands.

Agent Cards for zero-config discovery: Every agent publishes a small JSON file at /.well-known/agent.json that lists its endpoint, skills, and auth method.
Standard JSON-RPC 2.0 over HTTPS: Requests (tasks/send) and responses travel as JSON-RPC messages on plain HTTPS, so agents in any language interoperate through existing API gateways or mTLS proxies.
Built-in auth with short-lived tokens: Tokens scoped per task and expiring in minutes eliminate long-lived secrets while integrating with enterprise SSO, a key cybersecurity best practice for identity-aware systems and zero trust architectures.
Flexible interaction patterns: Uses a blocking call for quick answers and tasks/sendSubscribe for long tasks. Gives real-time updates via Server-Sent Events (SSE). Agents can even push webhooks for fully async workflows.
Rich, multimodal data exchange: A single task can bundle text, JSON, files, images, or audio as separate “parts,” allowing agents pass artifacts logs, screenshots, CSVs without inventing new MIME schemes.
Versioning & vendor-neutral extensibility: The spec includes a compatibility flag so new features roll out without breaking older agents. The A2A Apache-2.0 license prevents any one vendor from locking the rest out. On July 31, 2025, A2A version 0.3 was released—adding gRPC support, signed security cards, and extended Python SDK support; the protocol now counts over 150 supported organizations.

How to Adopt the Agent-to-Agent (A2A) Protocol in 6 Practical Steps

Follow this step-by-step guide to adopt your first A2A agents and weave them safely into your workflow.

Step 1: Install the Sample Toolkit

Clone Google’s reference repo and drop it into the Python SDK.

git clone https://github.com/a2aproject/a2a-samples.git
cd a2a-samples
python -m venv .venv && source .venv/bin/activate
pip install a2a-python            # or a2a-js for Node

The repo includes basic example agents and lightweight helper code for JSON-RPC calls and SSE streaming, but production implementations will need hardening.

Step 2: Launch a Demo Agent

Pick one of the ready-made agents (e.g., the “currency” FastAPI service) and run it.

uvicorn samples.python.currency_agent:app --port 10000 --reload

When the server starts, it auto-serves an Agent Card at: https://localhost:10000/.well-known/agent.json, advertising its skills and auth method.

Step 3: Expose the Agent Card

Make that JSON file reachable via a public URL, an internal LB, or a registry entry. Other agents can pull it and learn who you are and how to talk. No extra service-discovery layer is required. For production environments, agents can also publish to a centralized A2A registry, which supports indexed search and simplifies discovery across large infrastructures.

Step 4: Hook in Short-Lived Auth

Edit the auth block in the Agent Card to point at your OIDC or token issuer and set the TTL to minutes. Every task call will now carry a scoped, self-expiring token instead of a long-lived secret.

Step 5: Send a Task and Stream the Result

From another agent (or just curl), invoke the first agent:

TOKEN=$(<your_token_here> --ttl 5m --aud currency-agent)
curl -H "Authorization: Bearer $TOKEN" \
     -X POST https://currency-agent:10000/tasks/sendSubscribe \
     -d '{"input":{"amount":"50","from":"USD","to":"JPY"}}'

The request uses JSON-RPC 2.0 over HTTPS; the sendSubscribe variant opens a Server-Sent Events stream, so you get live status until completed.

Step 6: Watch the Traces

The SDK emits OTLP logs/metrics with a shared trace ID. Point OTLP logs and metrics to your backend of choice for unified observability.

Security Automation for Safe A2A Implementation

The Agent-to-Agent (A2A) Protocol enables software agents to trade tasks and data on the fly, but it truly shines when access is tightly controlled and fully auditable. Apono and the A2A Protocol share a key mission: enabling secure, policy-driven access between non-human identities (NHIs) like service accounts, bots, and APIs. Apono ensures that, even as NHIs interoperate across boundaries, their access is ephemeral, precisely scoped, and compliant.

Apono’s platform is purpose-built to manage access for NHIs by enforcing Just-In-Time (JIT) and Just-Enough-Privilege (JEP) access, thereby reducing standing privileges and misconfigurations. It ensures every service account, bot, or API key gets only the access it needs for exactly as long as it’s needed.

Apono is designed to become the enforcer of orchestrated permissions across infrastructure by automating and right-sizing the lifecycle of access for NHIs—including provisioning, expiration, and auditability—to install least privilege for NHIs and bring zero trust to all of your identities.

With Apono’s auto-expiring tokens and centralized logs, you can narrow the window for misuse and provide security teams with a single source of truth when compliance and auditing questions arise.

Get hands-on with Apono. Request a demo to deploy in under 15 minutes and start eliminating overprivileged access.

Build vs. Buy Access Control: Why Apono Is the Smarter Choice for Cloud & Security Teams

The Access Management Dilemma in Hybrid Environments

Security and engineering teams today face a tough balance: protecting sensitive resources while keeping developers productive. As organizations shift from on-prem to the cloud, access management becomes one of the biggest challenges.

With more identities—human and non-human—gaining access to more resources across hybrid environments, the risks rise. Studies show that over 95% of identities hold excessive privileges, and attackers are exploiting this reality, with 88% of breaches starting from compromised identities.

It’s natural for engineering teams to want to “build” their own Just-in-Time (JIT) access solution. But is that really the best use of resources? Increasingly, organizations are asking themselves:

Should we build an in-house solution or buy a platform that delivers secure, scalable JIT access out-of-the-box?

This article explores the trade-offs of building vs. buying so you can make the right choice for your organization.

The Real Costs of Building Your Own JIT Access Management

Rolling your own JIT solution sounds simple, but in practice, it’s often a patchwork of services, scripts, and ongoing maintenance.

What it takes to build:

Provisioning logic: Microservices or Lambdas to trigger access grants/revocations.
Rules engine: Custom service to decide who can request what.
Integrations: Connectors for each cloud, app, and service.
Role management: Mining roles, setting up RBAC, auditing usage.

The hidden cost:

Every API change or new service means potentially new engineering work, requiring design, development and testing.
DIY systems are usually scoped for niche apps. Not broad coverage leaving huge gaps including how to support the rest of the identity fabric and related tools.
Continuous upkeep and testing drains developer time and slows agility.

In short, the challenge isn’t just building. It’s maintaining, its testing, its patching and scanning for vulnerabilities. It’s having a team to support you.

💡 Thinking about building your own solution?
See how leading teams evaluate Cloud PAM platforms before they commit. Download the Access Platform Buyer’s Guide here

Build vs Buy Comparison Table

Factor	Build In-House	Buy a Platform (General)	Apono Advantage
Speed to Deploy	Months to design, develop, and test, resulting in a slower time-to-value.	Typically faster deployment with vendor-provided integrations and support.	API-first deployment with Terraform, Helm, CloudFormation; Slack/Teams-native workflows for fast adoption.
Role Creation Model	Often depends on pre-created roles — slow to adapt, prone to over/under-privilege.	Many solutions offer role management, which may require predefined roles or templates.	Dynamic roles created in real time, scoped to the task, auto-expire, and adapt automatically to business context.
Coverage	Limited to your team’s integration work; gaps likely in multi-cloud/SaaS.	Most vendors offer coverage across major cloud and SaaS platforms, but breadth and depth can vary.	Comprehensive support across AWS, Azure, GCP, Kubernetes, SaaS, and NHIs; single-pane-of-glass management.
Operational Overhead	Continuous upkeep for API changes, security patches, and policy logic.	Vendor-managed updates and maintenance help reduce the burden on internal teams.	Fully vendor-managed with continuous support for new APIs; automated discovery reduces admin effort.
Customization	Fully tailored to unique workflows and niche systems.	Platforms typically offer policy frameworks and workflow flexibility, though some adjustments may be needed.	Granular Access Flows and contextual policies, easily adapted to customer workflows without brittle custom code.
Security Posture	Risk of drift if roles aren’t updated quickly; harder to keep least privilege.	Most platforms provide controls for enforcing least privilege, although they are often tied to predefined structures.	Real-time context evaluation ensures least privilege with just-in-time and just-enough access; supports NHI quarantine.
Slack / Jira Integration	Requires custom development and ongoing maintenance.	Many platforms offer some integrations, with varying depths.	Deep Slack, Teams, and Jira integrations for request → approve → provision flows.
Auto-Expiring Roles	Must be built and maintained manually with custom scripts.	Some vendors provide time-limited role options.	Native auto-expiring, context-aware roles scoped to the task.
Audit Logging	Logs are often fragmented across different systems, requiring manual correlation.	Platforms provide centralized logging, but the depth can vary.	Unified session auditing with identity-to-action tracking, SIEM & ticketing integration.
Deployment	Complex build-out requiring internal engineering resources.	Vendor platforms usually offer guided setup and professional services.	Fast, API-based deployment with pre-built integrations and self-service rollout.

Apono’s Secure by Design Architecture

They say never roll your own crypto—because with great power comes great responsibility. The same applies to JIT access. It holds the keys to your most sensitive crown jewels, so protecting it must be a top priority.

Whether it’s a Lambda function or another microservice handling provisioning, it carries a lot of permissions. The real question: how are you ensuring it can’t be compromised, thereby handing attackers the keys to the kingdom?

Apono’s patented secure architecture keeps your environment fully in your control. Our platform runs on two lightweight components:

The Web App – where admins create and manage access flows. It never touches your data or resources.
The Connector – deployed inside your cloud, fully under your control, executing only pre-defined actions and never storing secrets.

Why it matters:

No data exposure – Apono never reads your files, code, or datasets.
Secrets stay secret – Credentials are pulled directly from your cloud’s secret store and never cached.
Always available – High-availability design ensures access flows keep running without downtime.
Compliance built-in – Password resets and credential rotation are enforced automatically.

With Apono, all access stays in your environment—you get secure, reliable, and compliant access management without friction.

What Engineering Leaders Are Choosing

Monday.com transitioned from maintenance-heavy in-house workflows to a secure, scalable, and developer-friendly platform—powered by Apono

ROI at Scale

14,600+ developer hours saved per year through instant, auto-approved access.
3,800+ DevOps hours saved per year by eliminating manual access handling.
18,000+ hours reclaimed annually while strengthening compliance and reducing risk.

ROI Of Your Internal Resources Is On What You Can Sell

If you’re managing access to a niche or one-off resource, building something in-house might feel tempting. But the reality is that most teams quickly learn the cost is higher than the benefit: ongoing maintenance, constant patching, compliance reviews, and dedicating precious engineering cycles to “plumbing” instead of product.

Modern teams need speed, security, and scalability—not another internal project to babysit. A proven cloud-native JIT access management solution delivers reliability out of the box, reduces risk, and frees your engineers to do what they do best: ship value to customers.

Don’t Build What You Could Buy Smarter.

Download the Buyer’s Guide to learn how leading security teams compare Cloud PAM platforms — and why Apono is built for speed, scale, and Zero Standing Privilege.

7 Man-in-the-Middle (MitM) Attacks to Look Out For

Today’s man-in-the-middle (MitM) attacks go far beyond coffee-shop Wi-Fi: they target browsers, APIs, device enrollments, and DNS infrastructure. Using automated proxykits and supply-chain flaws, attackers hijack session cookies, tokens, and device credentials—turning one interception into persistent, high-value access.

Concerningly, these are not edge cases. Automated cyber threat activity surged 16.7%, with over 1.7 billion stolen credentials circulating on the dark web—fueling a 42% increase in credential-based targeted attacks. Passwords and simple MFA fail unless access is limited and continually verified.

Security teams can implement best practices, such as cutting token lifetimes and just-in-time elevation, to protect against man-in-the-middle attacks. Let’s review a comprehensive list of security controls you can implement immediately to make intercepted credentials worthless to attackers.

What are man-in-the-middle (MitM) attacks?

A man-in-the-middle (MitM) attack happens when an attacker secretly intercepts and manipulates communications between two parties. The attacker is positioned in the “middle” of the data exchange, between a user and an app, or between two users or two apps, without anyone noticing. With MitM attacks, the adversary can eavesdrop, steal credentials, alter data, or impersonate one of the parties involved.

Today’s MitM attacks target API calls, machine-to-machine traffic, and even naive agent-to-agent protocols in distributed, cloud-native environments. With stolen tokens or cookies, an attacker gains the same level of visibility and control as a legitimate service account.

Some examples of MitM techniques include:

Eavesdropping/sniffing: Capturing unencrypted traffic (credentials, config).
Message tampering: Altering data in transit (API responses, payloads).
Session & credential theft: Stealing cookies, tokens, or certs to impersonate users/services.

A successful man-in-the-middle adversary gains the same level of visibility and control as the legitimate user or service. Non-human identities (NHIs)—like service accounts, workloads, and agents—are particularly vulnerable. In fact, machine identities now outnumber human identities by as much as 80:1, multiplying the blast radius of a single interception. Without a strong enterprise identity management strategy, these identities are often left overprivileged and unmonitored, creating an easy path for MitM attackers.

7 Man in the Middle (MitM) Attacks to Look Out For, Plus Security Best Practices

MitM attacks aren’t just theoretical risks; they can be the cause behind real breaches or even large-scale espionage campaigns. Let’s review the most relevant attack types that DevOps and engineering need to watch out for.

1. Classic HTTPS Spoofing and SSL Stripping

Attackers downgrade HTTPS connections to plain HTTP, eliminating the security layer of SSL/TLS. This attack vector leaves communication in plaintext, including login credentials, API keys, and session tokens. Misconfigured certificates, outdated systems, or user dismissal of browser warnings leave room for SSL stripping. DevOps teams are especially concerned about this in CI/CD pipelines and API endpoints, as a single misconfigured connection can become the entry point of a MitM attacker.

Example: The 2015 Superfish adware fiasco showed how software that installed its own root certificate could intercept HTTPS traffic by trusting a single private key. Because those certificates shared a key, anyone with the key could impersonate sites (including banks) without browser warnings.

Security best practices:

Enforce TLS 1.3 across all applications and services.
Use HTTP Strict Transport Security (HSTS) to prevent downgrade attempts.
Automate certificate renewal and rotation to reduce the risk of expired or misconfigured certificates.
Build a structured validation plan to ensure TLS configurations and certificate management are consistently tested across environments.

2. DNS Spoofing (Cache Poisoning)

DNS hijacks and registrar compromises let attackers redirect entire domains to malicious infrastructure.

Example: Sea Turtle was a sophisticated espionage operation uncovered in 2019. Attackers targeted domain registrars, registries, and other DNS infrastructure to compromise DNS records and surreptitiously redirect traffic for targeted organizations to attacker-controlled servers. It allowed the attacker to intercept web and email traffic, steal credentials, and even serve forged or fraudulently issued TLS certificates to avoid immediate detection.

Security best practices:

Enforce DNSSEC and monitor DNS records via passive-DNS feeds (alert on unexpected delegations).
Lock registrar accounts with MFA and role separation; require multi-person approval for DNS changes.
Use certificate transparency and automated cert monitoring to detect fraudulent issuance quickly.
Use a cloud-native access management platform that limits what compromised DNS traffic can expose, since JIT access makes sensitive tokens and API keys time-bound.

So, what would these best practices look like in practice? Let’s look at an example. Caris Life Sciences used Apono to enforce JIT folder-level permissions in AWS S3—so even if DNS traffic were redirected, attackers couldn’t leverage long-lived standing credentials.

3. ARP Spoofing in Internal Networks (LAN-level MitM)

Attackers poison ARP tables on local networks to force traffic to flow through a malicious host, enabling sniffing and tampering with internal traffic.

Example: Pentest and tool writeups repeatedly show that cheap implants (like Wi-Fi Pineapple and Raspberry Pi) enable LAN ARP attacks. Effective data center management, such as strict network segmentation, helps reduce exposure to LAN-level MitM attacks.

Security best practices:

Segment east-west traffic using VLANs and microsegmentation.
Deploy IDS/IPS rules for ARP anomalies and enable switch port security (sticky MACs, BPDU guard).
Encrypt internal service traffic (mTLS) so LAN sniffing yields little usable data.
Microsegmentation plus JIT permissions ensures that even if lateral movement is attempted, overprivileged standing access isn’t available.

4. Wi-Fi Eavesdropping & Rogue Access Points (Evil-Twin attacks)

Threat actors use evil twin or malicious hotspots to steal users and proxy or intercept their traffic. This type of attack happens frequently in airports, public charging points, cafes, and hotels.

Example: In July 2024, Australian police arrested an individual for operating an “evil twin” hotspot that harvested travellers’ credentials by redirecting victims to spoofed login pages.

Security best practices:

Enforce VPN and device posture scans on all non-trusted networks; disable auto-join for enterprise devices.
Educate staff to verify SSIDs and employ certificate-pinned applications on high-value services.
Enforce 802.1X/enterprise Wi-Fi with device certificates and scan for duplicate SSIDs on the network.
Integrate network posture scanning with JIT access to sensitive assets so access from high-risk networks is denied or further challenged.

5. Session Hijacking/Token Replay (Stolen Cookies & API Keys)

Attackers replay stolen session cookies, tokens, or API keys to impersonate services or users, often without passwords. Stolen cookies and tokens don’t just result from MitM attacks; client-side flaws like cross-site scripting (XSS) can also expose session data and API keys, as seen in CVE-2024-44308.

Example: In the Microsoft SAS Token Leak (2023), researchers inadvertently published a Shared Access Signature token granting full access to an Azure Storage account and exposing 38TB of sensitive data. This NHI breach showed the risks of over-permissive, long-lived tokens.

Security best practices:

Ensure all tokens and permissions are short-lived, scoped, and auto-expiring. That way, even if an attacker captures a valid token, it becomes useless almost immediately.
Use device-bound tokens or certificate-based device auth.
Detect impossible travel/concurrent sessions and trigger immediate token revocation.
A cloud-native access management platform (like Apono) ensures all permissions are short-lived, scoped, and auto-expiring. A stolen token from an intercepted session becomes useless within minutes.

6. Agent-to-Target Hijacks (Compromised Agents & Telemetry)

An attacker with network access (or who exploits a vulnerability in an agent) can intercept or impersonate the agent to server telemetry and commands, hijacking workflows and observability channels.

Example: The Okta Support System Breach in 2023 saw attackers exploit a compromised NHI (a service account) to steal support artifacts containing customer credentials. Additionally, CVE-2025-1146 (CrowdStrike Falcon Linux component) illustrates how TLS validation bugs can enable MitM of agent to cloud traffic.

A potential MiTM attack exploiting this flaw could trick the vulnerable CrowdStrike sensor into accepting a malicious, non-legitimate server certificate. This attack would allow the attacker to intercept, decrypt, and manipulate the secure communication between the sensor and the CrowdStrike cloud, potentially compromising system confidentiality and integrity.

Security best practices:

Enforce strict TLS validation and mTLS for agent-to-cloud links.
Limit agent privileges; require JIT elevation for sensitive operations.
Log agent activity and alert on anomalous command sequences.
Apono enforces JIT approvals on sensitive agent actions, so even a compromised agent account cannot escalate beyond its narrowly scoped, temporary role.

7. Naive Agent-to-Agent Protocols (Weak Inter-Agent Auth)

Simpler or unrecorded agent-to-agent protocols without mutual authentication or request signing enable MitM between agents and services in distributed systems. Such attacks may include context poisoning, agent impersonation, or exploiting an AI agent’s logic.

Example: Microsoft’s Taxonomy of Failure Modes in Agentic AI Systems warns how impostor agents could intercept agent communications. The research shows that an attacker could introduce an impostor AI agent, such as an impostor “email assistant,” into a network of cooperating agents. This malicious actor would then have the capability to intercept and alter legitimate communication between other actors, such that the attacker can inject new instructions and pilfer sensitive data without intervening directly by any human user.

Security best practices:

Mandate mutual TLS and cryptographic signing for agent-to-agent calls; mandate strict key rotation.
Adopt centralized identity for services (machine identities), per-call authorization, and least-privilege policies.
Validate request provenance and use replay protection (nonces/timestamps) in protocols.
Machine identity management should be centralized. JIT per-call permissions prevent overprivileged service accounts from being an ongoing MitM target.
A cloud-native access management platform like Apono manages machine identities and issues per-call JIT access, ensuring overprivileged service accounts aren’t a standing MitM target.

Where legacy PAM relies on static roles and vault proxies, leaving windows of opportunity open for MitM actors, Apono operationalizes Zero Standing Privilege. That means every credential, token, or role is short-lived, scoped, and continuously verified—dramatically reducing the blast radius of a single interception.

Short-Lived Access, Long-Lasting Security With Apono

Man-in-the-middle attacks typically succeed when stolen credentials or tokens remain useful. The fastest prevention isn’t perfect encryption; it’s limiting how much data of value an attacker has. Make sessions transient, bind tokens to device and context, and identify proxying traffic so stolen credentials will decay or be revoked right away.

Operationally, focus on three levers: mandate phishing-immune MFA and device-bound authentication; use short-lived, auto-rotating tokens with per-call authorization and mTLS for traffic to services; and put high-risk activities behind human approvals and quick revocation playbooks. These steps keep attackers from turning a fleeting interception into a sustained breach.

Stolen tokens expire within minutes with Apono, preventing attackers from turning an interception into sustained access. Permissions expire automatically, machine identities are scoped per-call, and sensitive actions require approvals. Apono is built specifically for this approach: JIT access, automatically decaying permissions, scoped control over agents, and full audit trails reduce the blast radius in case of interceptions. See how temporary access turns the tables. Apono operationalizes zero trust by eliminating standing privileges across human and machine identities.

Book a demo and start making stolen credentials useless before they can be weaponized.

Minimize and time-limit privileges for machine identities across automations, services, pipelines, and environments.

Addressed risks: Over‑scoped tokens or long‑lived service accounts

Implementation:

Inventory all NHIs (service accounts, bots, API keys, etc.)
Assign owners to all NHIs
Tag environment and purpose for all NHIs
Replace static credentials with short‑lived, scoped tokens
Issue per‑task credentials with automatic revocation
Add break-glass roles for extra approvals with strict time limits
Log all NHI activity
Review NHI access logs on a regular basis (weekly/monthly)
Automatically disable dormant accounts

Apono automates ephemeral, scoped permissions on demand (via Slack/CLI), auto‑expires them, supports break‑glass and on‑call flows, and records who/what/why for compliance. With You can automate JIT/JEP approval flows so elevated scopes are granted only when needed and set to auto‑expire.

3) Code Secret Management & Rotation

Centralize code secrets management, make sure no secrets leak into code/repos/configs, and rotate secrets automatically and frequently.

Addressed risks: Key leaks in repos or public tools/workspaces, as well as long-lived keys, are difficult to revoke across complex environments.

Implementation:

Store credentials in a secrets manager
Inject at runtime via env/sidecar
Never commit secrets to VCS or public workspaces
Enable pre‑commit and CI secret‑scanning
Add organization‑wide repository protections and real‑time code secret detection

4) Abuse Prevention Guardrails

Employ gateway and applications to prevent brute‑force, enumeration, and volumetric abuse. Implement strict schema validation to stop mass assignment and injection.

Addressed risks: DoS attacks, credential stuffing, data harvesting, and business‑logic abuse.

Implementation:

Enforce client-based quotas and PRS limits
Employ burst buffers and backoff
Return 429 with Retry-After
Add IP/ASN reputation, device fingerprints, and geo policies for public APIs
Apply WAF/API firewall rules for known bad patterns

5) Identity and Request Level Monitoring, Logging, and Auditing

Maintain centralized, immutable logs and real‑time monitoring tied to who/what called which API, with what scope, and why.

Addressed Risks: Blind spots that delay detection, resulting in inadequate forensics, and compliance gaps.

Implementation:

Collect structured logs (JSON) from gateway and app layers
Include request IDs, subject identity (user vs. service account), scopes/roles, decision (allow/deny), and data classification tags
Ship collected logs to a central SIEM/observability stack
Enable API inventory and runtime discovery to spot shadow endpoints and drift

Apono correlates the who/what/why for elevated access via JIT/JEP approvals, and auto‑generates audit trails you can join with gateway logs for complete identity‑to‑request traceability.

6) Configuration Hardening

Implement robust security controls at the edge and mesh, with TLS everywhere, mTLS for service‑to‑service, strict gateway policies, and secure defaults.

Addressed risks: Downgrade attacks, credential stuffing, enumeration, and data exfiltration.

Implementation:

Enforce TLS version 1.2+
Pin modern ciphers
Set HSTS on public endpoints
Require mTLS or signed requests internally
Lock down CORS and allowed origins
Prefer deny‑by‑default routing
Apply gateway policies for authn/authz, RPS quotas, request size limits, schema validation, and WAF/WAAP signatures

7) Incident Response & Recovery

Prepare tested playbooks to quickly contain and recover from API security incidents. This step includes revoking secrets, quarantining identities, and more.

Addressed risks: Long dwell time, cascading outages, and non‑compliant disclosures.

Implementation:

Maintain runbooks for: global token/key revocation (“kill switch”), scope reduction, policy rollback, and credential re‑issuance
Pre‑stage scoped, short‑lived emergency roles
Practice blue/green rollout of rotated secrets
Rehearse comms and regulatory timelines
Snapshot and preserve logs

Apono executes one-click revocation of elevated permissions, issues ephemeral emergency auto-expiring access, and provides comprehensive audit logs for forensics and compliance reporting.

8) Safe Usage of Third-Party and Partner APIs

All upstream APIs should be treated as untrusted with required input/output validation, egress constraint, and tight scoping of partner credentials.

Addressed Risks: Supply‑chain data leaks, SSRF and injection via upstream responses, and over‑privileged partner integrations.

Implementation:

Terminate egress through a controlled gateway with DNS/IP allowlists
Enforce timeouts, circuit breakers, and retries with jitter
Validate and sanitize all upstream responses against strict schemas
Block unexpected fields
Filter PII at boundaries
Use per‑partner, per‑environment credentials with minimal scopes
Rotate credentials automatically

9) API Inventory and Classification

Maintain a complete and continuously up-to-date catalog of all APIs (internal, external, partner), classified by sensitivity and criticality to business processes.

Addressed Risks: Shadow or forgotten APIs become unmonitored attack surfaces.

Implementation:

Employ automated API discovery tools in gateways, service meshes, and CI/CD pipelines.
Tag APIs by environment (dev/stage/prod), data type (PII, PCI, PHI), and compliance requirements.
Record ownership for every API and require registration before deployment
Update API inventories with drift detection and runtime monitoring tools.

10) Secure API Design and Data Minimization

Apply “secure by design” principles during API development; minimize exposed endpoints, reduce data returned, and enforce schema validation.

Addressed Risks: Excessive data exposure and mass assignment.

Implementation:

Design APIs with least privilege in mind and expose only what is necessary
Implement schema validation for requests and responses
Reject unexpected fields
Mask or tokenize sensitive data fields (like SSNs and credit cards) wherever possible

11) Security Testing Throughout the SDLC

Treat API security testing as a continuous process integrated into development, and not a one-time event.

Addressed Risks: Vulnerabilities slip into production unnoticed, and late fixes are costly and risky.

Implementation:

Embed API security testing (SAST, SCA, fuzzing, pen testing) directly into CI/CD
Use contract tests and automated linting to catch insecure design early.
Continuously scan for leaked secrets and misconfigurations in code and IaC.
Re-test APIs after every significant change or deployment.

Apono ensures that any temporary testing credentials or elevated scopes are ephemeral, preventing testers from holding permanent, risky access.

12) Data Encryption in Transit and At Rest

Enforce end-to-end encryption for API traffic and secure sensitive data at rest with strong encryption and key management.

Addressed Risks: Sensitive data interception or theft.

Implementation:

Require TLS 1.2+ everywhere and disable weak ciphers.
Apply mTLS for internal service-to-service API calls.
Encrypt sensitive data at rest with strong cryptographic algorithms (AES-256).
Rotate encryption keys regularly and enforce least-privilege key access.

13) Governance & Ownership of Non-Human Identities (NHIs)

Extend identity governance to all bots, service accounts, API tokens, and workloads, ensuring every machine identity has an owner, lifecycle, and pre-defined scope.

Addressed Risks: NHIs that accumulate standing privileges and static secrets that attackers exploit.

Implementation:

Require owner assignment for every service account and token.
Define lifecycle processes for provisioning, rotation, and decommissioning of NHI accounts.
Automate access reviews for over-privileged or dormant NHIs.
Apply to NHIs the same zero-trust, authentication, authorization, continuous monitoring, and least privilege that are used for user accounts.

Apono automates JIT/JEP access for NHIs, eliminates standing privileges, and provides a centralized audit trail across all machine identities.

14) Compliance Alignment & Continuous Access Reviews

Conduct regular reviews of who or what has access to your APIs in accordance with relevant regulatory or industry-specific requirements, such as GDPR, HIPAA, PCI-DSS, and SOC 2. These reviews should extend beyond APIs themselves to include underlying cloud infrastructure and data center management, where API access often intersects with critical systems and regulatory controls.

Addressed Risks: Drift in access privileges that leads to overexposed data, and failed audits result in fines, lost business, and reputational damage.

Implementation:

Schedule regular (weekly, monthly, or quarterly) access certification campaigns across all your APIs.
Map API access to relevant compliance controls.
Document all review outcomes and remediations for audit readiness.

15) Secure Defaults and Engineer Security Training

Equip developer teams with secure-by-default patterns and ongoing training, so security isn’t bolted on but baked in.

Addressed Risks: Developers under deadline pressure may expose sensitive data or skip controls.

Establish secure API templates and SDKs with built-in auth, schema validation, and logging.
Conduct regular training and gamified workshops.
Integrate secure design patterns and secret scanning into CI/CD (“shift left”).
Set “secure by default” configurations in infrastructure and gateway tooling.

Apono reduces developer friction by streamlining access requests (via Slack/CLI) and ensuring secure defaults (temporary, least-privileged, and auditable) so engineers don’t need to over-grant permissions to maintain velocity.

16) Runtime Protections and Continuous Improvement

Treat this checklist as a living document. Integrate feedback and test controls, and add runtime protection to catch the vulnerabilities that may slip through.

Addressed Risks: Evolving threats and architectural changes to your environment that may introduce previously unfamiliar cyber risks.

Implementation:

Regularly review and update the checklist with newly published API security advisories.
Add runtime defenses like API anomaly detection and inline policy enforcement.
Run red-team simulations targeting APIs and integrate the conclusions into checklist updates.
Integrate threat intel to anticipate emerging API attack vectors.

Turning the API Security Checklist Into Action

An API security checklist operationalizes security by standardizing controls, aligning teams, and making protection repeatable. However, securing APIs is an ongoing cycle of auditing, monitoring, and enforcing least privilege, especially for vulnerable non-human identities. Apono steps in to automate Just-In-Time and Just-Enough Permission access, eliminate standing credentials, and provide full audit trails across every API interaction. Ready to close the gaps in your API security posture? Book a demo with Apono or download the checklist to put API security into action today.

Apono Releases MCP Server for End Users

We’re excited to announce the launch of our MCP server for end users, designed to boost engineering productivity while keeping security strong.

Engineers often know exactly what they need to do—deploy to a new environment, spin up a workload, investigate logs—but not which permissions translate into those tasks. That leads to two common problems:

Over-requesting: “Just give me admin.”
Workflow stalls: repeated Slack pings and ticket loops.

The result is wasted time, frustrated teams, and an inflated attack surface from unnecessary standing privileges. On top of that, engineers often spend extra time checking what they already have access to or chasing approval updates.

Why MCPs Matter

AI tools like Claude, ChatGPT, Cursor, and CoPilot are changing the way engineers interact with their environments. Instead of bouncing between dashboards, they can ask for what they need in natural language.

Model Context Protocol (MCP) makes this possible by connecting LLMs to enterprise systems so users can query, retrieve, and act without leaving their workflow. Think about them like the USB-C that connects your favorite AI services to the tools you use, simplifying the adoption of AI into your teams’ workflows.

How Apono’s MCP Server Works

Our Apono MCP Server applies this approach to access requests:

Interpret Intent – Understand the user’s goal.
Guide the Request – Prompt for missing info such as justification or duration.
Leverage Apono – Fetch context and match it with the right access flows.
Deliver Outcome – Grant access, initiate flows, or return structured answers.

What Users Can Do

With Apono MCP, engineers can:

Visibility into what they already have access to
Clarity on request status without chasing admins
Simpler resource discovery, even without the exact name
Frictionless access requests without clicking through dashboards
Faster resolution of permission errors
Less time wasted filling out forms

So how are users leveraging Apono’s MCP to solve problems? Let’s take a look at a few key examples.

Value Across the Lifecycle

The Apono MCP Server delivers clear benefits:

Accelerate Engineer Velocity: No more Slack threads or guesswork, just fast access.
Reduce Admin Load: Security and DevOps teams spend less time interpreting vague requests.
Promote Least Privilege at Scale: Rightsized access lowers risk and improves governance.
Boost Adoption: A simple, frictionless experience encourages teams to use Apono the right way.

Where You Can Use It

Our MCPs integrate with a growing number of the tools engineers already rely on:

IDEs: Cursor, CoPilot, Claude Code
Chat: ChatGPT, Claude, Gemini
Amazon Q: supported

Along with our MCP support, we recently launched our AI-powered Apono Assist for engineers on our platform, Teams, and other UIs. Read about it in this blog.

And don’t think that we’ve forgotten about the Apono admins. We will be launching an MCP server for Apono administrators soon so stay tuned for updates.

We’re also building support for securing MCPs as they become a standard part of enterprise workflows alongside the anticipated rise of Agentic AI.

Get Started

With Apono’s MCP Server, engineers request and manage access faster, admins spend less time translating requests, and security stays strong with least privilege built in.

Reach out to us to learn more about MCPs in Apono check out our docs and reach out to us for a demo today.

Beyond the Drift Breach: Securing Non-Human Identities with Zero Standing Privileges

The Drift OAuth breach didn’t just expose one SaaS vendor — it exposed a systemic blind spot: the sprawling, ungoverned world of Non-Human Identities.

In case you missed it, in August 2025, attackers from UNC6395 exploited compromised OAuth tokens from Salesloft’s Drift integration—an AI chat tool—to access and exfiltrate data from Salesforce, including credentials like AWS keys and Snowflake tokens.

This breach affected over 700 organizations and extended beyond Salesforce to integrations with Google Workspace and other platforms like Slack, AWS, and Microsoft Azure, just to name a few.

The first line of response has prompted a complete revocation of Drift tokens and disabling of significant numbers of related app integrations.

Since the initial news of the breach, we have learned that the attackers are combing through the exfiltrated stolen data in search of more tokens and credentials that they can use for further criminal activities.

In this blog, we’ll cover why Non-Human Identities like API tokens can cause serious security challenges for organizations and explore how smarter access management approaches can help to reduce risk without compromising on operational efficiency.

Why API Tokens are Risky

API tokens act like digital keys that let SaaS products and business systems talk to each other securely.

Instead of sharing a username and password, a token gives controlled, time-limited access to exactly the data or actions a system needs. This enables automation and collaboration between tools (like a SaaS app pulling data from a business system) while reducing the risk of exposing full credentials.

But as we’ve seen here and in plenty of cases before, these tokens are exceedingly risky if they are compromised. And even more dangerous when they’re not managed properly.

If we think about these tokens like the keys they are, then they are essentially keys to our kingdom with privileges that attackers can use to access our resources.

These powerful tokens come with several significant challenges, including:

Lack of visibility – Lots of people in the organization spin up tokens like all principals and NHIs, but nobody is really doing a sufficient job of tracking them. This means that they can sit around hidden in environments with their standing privileges, and nobody knows they are still there or how they’re being used.
Poorly managed – When you don’t know what you have, it’s hard to manage them. Best practices call for rotating credentials and tokens but because of the lack of visibility and good processes, this can fall between the cracks.
Excessive privileges – Usually out of convenience, NHIs and principals are given way more privileges than they really need. This overprivilege unnecessarily expands the blast radius and can make an attack way worse if the principal is compromised.
Remediation is risky – Reducing risk for principals isn’t as straightforward as simply removing them or their privileges. Because principals, such as tokens, are built into infrastructure or processes, removing them can break workflows and impact the organization. The result is that many security teams prefer to risk an incident than break their infrastructure.
Legacy tools haven’t caught up – IGA and PAM tools that were built for the on-prem era, when privileges were far more static and NHIs hadn’t really come on the scene yet, don’t provide sufficient solutions for principals. They cannot detect them, let alone manage them. More modern, dedicated NHI tools have improved visibility, but are less effective in reducing risk through effective access management.

All of these problems are amplified by the sheer scale of NHIs. Industry research estimates ratios ranging from 40:1 today to projections of 100:1 or more with AI adoption.

And as organizations adopt more AI, this number is likely to skyrocket. The impact will be a massive expansion of the attack surface, providing even more opportunities for hackers to exploit the situation.

Attackers Targeting Identity in the Supply Chain

While attribution is far from a hard science, all signs point to this hack being the work of the loose collective of criminals associated with the Com. We usually read about them under names like LAPSUS$, Scattered Spider, and Shiny Hunters.

These hackers have made a name for themselves in focusing on identity as their main point of entry and exploitation. They’ve been behind the MGM, Okta, Snowflake, and other big name hacks. They employ methods such as social engineering and possess a deep understanding of identity and access management (IAM) to compromise identities and infiltrate target systems.

What they have shown in their attacks is that they can exploit the human and non-human identities as part of a successful attack, compromising identities and leveraging their privileges to steal or encrypt targets’ data.

There’s an argument to be made that these crews are far less technical than the hackers of the previous era who spent months looking for ways to exploit a vulnerability or find a zero day.

In many cases, they have been shown to simply buy access from a broker, pay off employees at the phone company for a SIM swap attack, or call up the help desk and ask for a password reset.

But it’s not stupid if it works, and these criminals have the illicit paydays to prove it.

Unfortunately, these groups have discovered that while they can successfully target large enterprises, the path of least resistance is often to attack a vendor in a supply chain attack.

Especially if the vendor is less mature in terms of security, they can exploit it to slither their way up the chain and become a bigger, richer target.

If a vendor finds themselves targeted in a supply chain attack, it can have serious reputational, not to mention financial pains as companies are less likely to trust them with their data and access to their systems moving forward.

Actionable Takeaways – How to Protect Against the Salesloft Drift Incident

In the immediate aftermath of this incident, here’s what security teams can do right now to reduce exposure:

Audit and revoke stale OAuth tokens.
Rotate embedded secrets immediately.
Enforce least privilege across OAuth scopes.
Treat AI agents as first-class identities in your IAM model.

Moving Towards a Unified Approach for Human, Non-Human, and Agentic AI Identities

One of the key takeaways from this story is that we shift our mindset. Security must move from protecting only human access to governing every identity that can touch data, human or not.

The targeting of an AI tool here is interesting because it shows us that attackers understand that AI agents require a lot of access and freedom of movement between applications to be effective. That’s a lot of connectivity that can be exploited to gain access to different systems that they can take advantage of and it puts defenders in a bit of a conundrum that is as old as time.

Do we let our AIs run free and maximize the benefits of what they can give us or do we tightly control access to limit damage from abuse?

The challenge with Agentic AI is that it is:

Very much goal oriented
Has no ability to think about if something is a good idea (like deleting your production DBs and then lying about it later)
Doesn’t behave like NHIs that have very predictable and repetitive actions

An agent will access whatever it thinks it needs to in order to achieve its goal. In this way it’s like a human user.

But the scale and lack of visibility of Agentic AI is going to be a challenge for security teams moving forward.

So how should security teams think about mitigating risk from Agentic AI and all the rest?

How Apono Enables Secure NHI Access Management

Security teams need to take a flexible approach that breaks down the silos of human, non-human, and now Agentic AI identities, all of which are essentially on the same plane. It should matter less who or what the identity is and focus more on the access and how privileges are used.

Remember that the hackers don’t see your environment as a silo, so you shouldn’t either. Move your human users over to Just-in-Time access for sensitive resources and reduce privileges for all, including your NHIs, based on what they actually use and your risk.

From Apono’s approach, we put the focus on the principals and give admins granular controls over what privileges those principals, like API tokens, have.

We start by providing full visibility and inventory management principles throughout your environment.

In practice, we detect risks like:

Dormant Principals: Identities unused for 90+ days
Unused Privileges: Granted but unexercised access
Overprivileged Permissions: Permissions beyond actual usage needs

We then enable you to take remediation actions like :

Quarantine: Isolate risky access with pre-built guardrails or ready-to-use JSON deny policies for your cloud
Rightsize: Automatically adjust access to fit actual use
Delete: Revoke access or delete principals that are no longer needed

There are some distinct advantages to the quarantine option because it allows you to:

Take immediate mitigative action to eliminate risk without tearing out whole principals or NHIs, which can be highly disruptive to active workflows and infrastructure
Implement deny policies within a principal to block usage of specific unused or otherwise risky privileges while leaving the others active
These policies are managed in our Access Flow guardrails that are easy to manage and are quickly revertible, meaning that security teams can confidently take protective action

Embracing the Opportunities of AI in your Organization

Phishing, credential theft, and breaches happen. They will continue to happen because the financial incentives are there.

We are past the stage of assuming breach. Now we need to assume that our identities (human and non-human like API tokens, service accounts, and more) are compromised.

Attackers can now leverage all of their access privileges to not only access resources in your environments, but also to find more tokens, credentials, etc that they can use to continue their attack. This might be pivoting to additional systems or to your customers’ customers.

If your customers trust you to securely handle their data, then you need to make sure that you are taking sufficient precautions to protect them. As more incidents of big companies getting compromised by way of their vendors hit the headlines, we can expect them to demand more from their vendors if they want to do business with them.

As the business world becomes more and more connected with machine identities and AI agents relying on tools like API tokens to communicate with each other across platforms, organizations will have to step up their game to ensure that they are a step ahead of the criminals.

This means being responsible by following best practices and embracing automation to handle the scale, but also not being afraid to embrace the opportunities that AI agents are offering us for greater productivity and growth.

Ready to Take Action?

To learn more about how Apono is enabling organizations to confidently embrace the AI-driven future, reach out to us today and start the conversation.

Or, try our Cloud Assessment for NHIs to uncover hidden risks in your AWS environment and explore smart remediation solutions powered by Zero Standing Privileges.

Object	JIT Controls / Best Practices	Why It Addresses Shai‑Hulud / S1ngularity Risks
Repositories	Require elevated repo‑write or admin roles only for specific tasks and time‑boxed sessions.Monitor postinstall / workflow scripts changes and prevent unreviewed workflows being added.Make repo‑admin write privileges conditional: e.g. dual approval, MFA, etc.	Shai‑Hulud relies on compromised developer accounts injecting malicious code; automation that elevates privileges in repos can be abused. Time bounding helps limit how long a repo is potentially exploitable. Vulnerable workflows were shown to have been exploited in the S1ngularity incident.
Organization Roles	Limit the number of owners / admin roles. Use JIT elevation (a user requests elevated privileges, with justification, for a fixed time).Require MFA to secure approval workflows.Maintain active logging, alerts for creation / removal of owners or admin roles.	Owner/admin roles are what attackers used to propagate, exfiltrate, create repos, change visibility. In S1ngularity, tokens with owner/admin or elevated scopes allowed workflows to be abused.
Teams & Inherited Permissions	Use temporary-team assignments or request elevated permissions for specific time only.Disallow teams from being owners / admins unless needed; if they must be, audit their membership and actions.	Inherited permissions mean one compromised user in a team can impact many repos; teams with admin rights can act like many owners. The worm & leaks exploit exactly that scale.

Identity and Access Governance (IGA): Definition & Differentiation Explained

What is identity and access governance (IGA)?

Core capabilities of Identity and Access Governance

IGA, IAM, and PAM Compared

Table 1: IGA vs IAM vs PAM

5 Challenges of Implementing IGA in Cloud-Native Environments

1. Scaling Ephemeral Identities

2. Complex Permissions

3. Friction with Development Teams

4. Non-Human Identities

5. Fragmented Visibility

How Modern IGA is Evolving

Bringing Automation to the Center of Governance with Apono

Inside the Crimson Collective Attack Chain—and How to Break It with Zero Standing Privileges

Breaking Down the Attackers’ Methodology

The Cloud Identity Challenge

How Apono Helps

What is Agent2Agent (A2A) Protocol and How to Adopt it?

What is the Agent2Agent (A2A) Protocol?

How does the Agent2Agent Protocol work?

1. Discovery with an Agent Card

2. Auth in Micro-slices

3. Task Exchange Over Web Standards

4. Built-in Observability

What is the Agent2Agent Protocol designed to do?

Why is the Agent2Agent Protocol a good thing?

Plug-and-Play Interoperability

Built-in Security

Less Glue Code, Faster Pipelines

Enterprise-Grade Observability

Agent2Agent Protocol Design Principles

How to Adopt the Agent-to-Agent (A2A) Protocol in 6 Practical Steps

Step 1: Install the Sample Toolkit

Step 2: Launch a Demo Agent

Step 3: Expose the Agent Card

Step 4: Hook in Short-Lived Auth

Step 5: Send a Task and Stream the Result

Step 6: Watch the Traces

Security Automation for Safe A2A Implementation

Build vs. Buy Access Control: Why Apono Is the Smarter Choice for Cloud & Security Teams

The Access Management Dilemma in Hybrid Environments

The Real Costs of Building Your Own JIT Access Management

Build vs Buy Comparison Table

Apono’s Secure by Design Architecture

What Engineering Leaders Are Choosing

Don’t Build What You Could Buy Smarter.

7 Man-in-the-Middle (MitM) Attacks to Look Out For

What are man-in-the-middle (MitM) attacks?

7 Man in the Middle (MitM) Attacks to Look Out For, Plus Security Best Practices

1. Classic HTTPS Spoofing and SSL Stripping

2. DNS Spoofing (Cache Poisoning)

3. ARP Spoofing in Internal Networks (LAN-level MitM)

4. Wi-Fi Eavesdropping & Rogue Access Points (Evil-Twin attacks)

5. Session Hijacking/Token Replay (Stolen Cookies & API Keys)

6. Agent-to-Target Hijacks (Compromised Agents & Telemetry)

7. Naive Agent-to-Agent Protocols (Weak Inter-Agent Auth)

Short-Lived Access, Long-Lasting Security With Apono

Top 10 Privileged Access Management Software Solutions

What are privileged access management software solutions?

Benefits of Privileged Access Management Software Solutions

Key Features of Privileged Access Management Software Solutions

How to Choose the Right Privileged Access Management Software Solution

Top 10 Privileged Access Management Software Solutions

1. Apono

2. StrongDM

3. Heimdal Privileged Access Management

4. Wallix Bastion

5. ARCON Privileged Access Management

6. Segura 360° Privilege Platform

7. ManageEngine Password Manager Pro

8. Systancia

9. Teleport

10. Netwrix (formerly SecureONE)

Why Apono is Built for Modern Enterprises

Want to Compare PAM Platforms Side-by-Side?

Shai‑Hulud worm and the Nx / S1ngularity attacks: How-to use JIT Access to Stop the Chain Reaction

TL;DR

What We Know

What We Learned from Shai‑Hulud worm and the Nx / S1ngularity attacks

Securing GitHub Actions with JIT