Big Story

Non-human identities are the primary mechanism through which systems access APIs. Applications, services, automation pipelines, and AI-driven workflows rely on credentials such as API keys, tokens, and service accounts to retrieve data and execute actions. These identities are created programmatically and used across environments, often without direct human interaction.

Recent data shows that 46% of organizations allow AI tools to access critical systems, while more than 40% report at least one security incident involving non-human identities in the past year. These figures reflect how widely such identities are used and how frequently they are involved in operational risk.

In many environments, these systems are granted permissions that extend beyond a single task or service. This simplifies integration but increases the scope of access associated with each credential. A single token or key may allow access to multiple APIs, datasets, or operational functions.

Credential exposure remains a common issue. API keys and tokens are frequently stored in application code, configuration files, and environment variables. They are also transmitted between services during execution. In distributed systems, these credentials may pass through multiple layers, including internal services, third-party platforms, and logging systems. Each step increases the likelihood of unintended exposure.

Once exposed, these credentials can be used directly to access APIs. Many systems treat possession of a valid credential as sufficient for authorization. Additional validation, such as context or intent, is often not enforced. This allows exposed credentials to be reused until they are revoked.

Credential lifecycle management is often incomplete. Non-human identities are created dynamically as part of deployment processes, integrations, and automation workflows. However, rotation and revocation practices are not always applied consistently. Some credentials remain active after the systems that generated them are no longer in use. Others are reused across multiple services, increasing their impact.

The number of active credentials increases over time. Each new service, integration, or workflow introduces additional identities. Without a mechanism to centrally track and manage them, these credentials accumulate across environments. This makes it difficult to determine which credentials are still required and which can be removed.

The behavior of non-human identities differs from that of human users. They operate continuously, execute actions at high frequency, and interact across multiple systems. This makes it harder to detect misuse based on traditional signals such as login patterns or session anomalies. Activity generated by these identities may appear valid, even when it is unintended or unauthorized.

API usage is directly tied to these identities. Most API calls in production environments are initiated by services rather than users. This means that API access depends on how credentials are issued, stored, and used. Weaknesses in credential management can lead to unauthorized data access, unintended system actions, and broader exposure across connected services.

For API and platform teams, securing access involves understanding where credentials are used and how. This includes identifying which systems generate credentials, where they are stored, and which APIs they can access. It also requires limiting permissions to specific actions and ensuring that credentials are rotated or revoked when no longer needed.

As systems scale, the number of non-human identities will grow. Each additional integration or automated workflow introduces new credentials. Managing these identities and their associated access is necessary to maintain control over API interactions and system behavior.

API Feed

Community Spotlight

Phil Sturgeon is an API design consultant and the author of Build APIs You Won’t Hate. His work focuses on how API design decisions affect usability, reliability, and long-term maintainability across systems. He has worked with organizations to improve API standards, documentation practices, and design consistency across distributed environments.

A consistent theme in his work is the importance of clear and predictable API contracts. APIs are often designed by individual teams based on local requirements, which leads to variation in naming conventions, request structures, and response formats. These inconsistencies create friction when APIs are consumed across teams or integrated into larger systems. Over time, this increases the effort required to maintain integrations and reduces the ability to reuse existing APIs.

He has also emphasized the role of standardization in reducing operational complexity. Defining consistent approaches to pagination, filtering, authentication, and versioning allows teams to build APIs that behave similarly across services. Without these standards, APIs evolve independently, leading to fragmentation and duplication of functionality.

Error handling is another area of focus. APIs frequently return inconsistent error responses, making it difficult for consumers to identify the cause of failures or take corrective action. Structured error formats, including standardized status codes and response bodies, improve both debugging and system reliability. This becomes more important in environments where APIs are consumed programmatically, as automated systems rely on predictable responses to function correctly.

His work also addresses the relationship between API specifications and implementation. In many cases, documentation and specifications do not accurately reflect deployed behavior. This gap creates issues during integration, as consumers rely on documentation that may be outdated or incomplete. Maintaining alignment between specifications and runtime behavior is necessary for reducing integration errors.

Sturgeon has also contributed to discussions on API style guides and governance practices, particularly in organizations that manage large numbers of APIs. His approach focuses on embedding design consistency into development workflows rather than enforcing it through manual review processes.

For API teams, these principles are relevant in environments where APIs are used across multiple services and employees. Consistent design patterns reduce integration overhead, improve maintainability, and support reuse. As systems scale, the cost of inconsistent API design increases, making standardization and clarity essential for long-term stability.

Resources & Events

apidays Singapore brings together API builders, architects, and platform leaders in one of Asiaʼs biggest fintech and digital transformation hubs, with a strong focus on how APIs are evolving for the AI and agentic era. The program blends practical case studies and technical sessions across API management, security, governance, and automation.

apidays New York is positioned as a high-density gathering for teams operating APIs at scale, with sessions spanning monetization, security, AI-driven automation, and platform governance. Itʼs built for senior practitioners and decision-makers, bringing together 1,500+ participants from 1,000+ companies, making it a strong anchor event for anyone tracking where enterprise API strategy is heading next.

FinOps X is the annual conference of the FinOps Foundation, focused on managing cloud and infrastructure spend across engineering and finance teams. The 2026 program includes sessions on cost allocation, optimization strategies, and tracking usage across cloud services and AI workloads. It also covers operational practices for managing variable consumption patterns, including usage-based pricing models and resource efficiency.

SpyCloud’s 2026 Identity Exposure Report analyzes identity data from breaches and malware to understand how credentials are exposed and reused across systems. The report identifies 65.7 billion identity records, a 23% year-over-year increase. It also recaptured 18.1 million API keys and tokens in 2025, many of which remain active and reused across services. The report notes that these credentials often lack additional safeguards and provide persistent access to APIs and cloud environments.

Insight of the Week

Most teams are exposing APIs directly to LLMs and calling it agentic, but the core issue is that probabilistic agents interacting with unstructured API surfaces create unpredictable execution paths, higher failure rates, and poor reproducibility. What’s emerging instead is a shift toward deterministic API workflows, where sequences of calls, error handling, and decision paths are predefined and machine-readable. Standards like Arazzo are pushing this model by defining end-to-end workflows (not just endpoints), effectively guiding agents through constrained execution paths while still allowing localized reasoning.

For the Commute

In this session, Naresh Jain explores how teams can evaluate whether their APIs are ready to support agent-driven workflows. The focus is on moving from static, developer-consumed APIs to systems that can be reliably used by AI agents operating dynamically across multiple steps. The talk highlights practical gaps teams encounter, including incomplete specifications, unclear contracts, and missing validation mechanisms when APIs are exposed to agents. It demonstrates how contract testing, service virtualization, and specification-driven development can be used to simulate agent interactions before deployment.

Stay tuned for bold ideas, fresh perspectives, and the next wave of API innovation

-The Apidays Team