Your next identity problem isn't employees. It's agents. HENNGE just built a company around that bet

Every identity program in a large enterprise is built around a person. Someone is hired, gets an account, joins groups, changes roles, and eventually leaves; access follows each step. Service accounts and API keys were always the awkward exception, managed in spreadsheets and rotated when someone remembered.

AI agents turn that exception into a population. An agent acts, often on someone’s behalf, sometimes on its own, across systems that were designed to trust a logged-in human. That is why a Japanese identity company’s announcement on October 1 is worth reading closely, even for teams that will never buy its products.

What HENNGE announced

HENNGE, best known in Japan for its HENNGE One identity and access platform, established a subsidiary called HENNGE AI to help organizations manage the cost and governance of enterprise AI.

Two parts matter.

The product plan. HENNGE AI’s first service is an AI Gateway that is planned to manage which generative AI models each user can access, show model costs with budget controls, apply security settings from company-wide down to individual level, and integrate with HENNGE One for single sign-on. Further out, HENNGE says it intends to build a unified authentication platform for non-human identities, including AI agents and bots.

Be precise about timing: the gateway runs internally at HENNGE today, and the commercial launch is scheduled for HENNGE’s fiscal year 2027, which ends September 30, 2027. The non-human identity platform comes after that. Nothing here is generally available.

The company design. HENNGE AI has two directors and no dedicated employees. According to HENNGE, a network of AI agents is meant to carry out software development, customer support, marketing and back-office work, while sales and some back-office functions stay with the parent company. It is an experiment, and HENNGE presents it as one. It is also the cleanest possible illustration of the identity problem: in a company with no employees, every actor that touches a system is a non-human identity.

Why agents break person-shaped IAM

Three properties make agents different from both employees and classic service accounts.

They act on behalf of someone, but not always. An agent may draft an email with a user’s delegated permissions in the morning and run an overnight reconciliation with its own permissions at night. Those are two different authorization models, and the logs need to say which one applied.

They are created fast and forgotten faster. A business team can build an agent in an afternoon. Nobody files a joiner request, and nobody files a leaver request when the project ends. OWASP’s Non-Human Identities Top 10 lists improper offboarding and overprivileged identities among the leading risks for this whole class of identities; agents inherit both.

Their permissions drift with their tools. Adding a connector to an agent is effectively granting it new access. If that happens in an agent builder rather than in the identity system, access reviews never see it.

1. Register agent with a human sponsor
2. Grant scoped access, per tool
3. Act: delegated or autonomous
4. Log every call with both identities
5. Review access each cycle
6. Reassign or retire when the sponsor leaves

Steps person-shaped IAM does not cover by default

Where the market already is

HENNGE is late to ship but early to name the category. Microsoft has already moved: Microsoft Entra Agent ID is generally available, with dedicated identity types for agents, administrative roles for owners, sponsors and managers, Conditional Access templates that distinguish agents acting on behalf of users from autonomous ones, and lifecycle workflows that transfer sponsorship when a sponsor changes roles or leaves, so agents are not orphaned. Microsoft also documents patterns for giving agents built on other platforms, including Amazon Bedrock and n8n, an Entra identity.

AWS took a related path in its runtime, giving each managed agent an IAM role, as we covered in our analysis of Bedrock Managed Agents. And identity governance vendors are pulling AI traffic into identity, as C1 did with its policy-controlled gateway, which we examined in our piece on AI gateways as policy enforcement points.

The direction is consistent: agent identity is becoming a first-class object in IAM, with an owner, a lifecycle and its own policies.

What to put in place now

You do not need to wait for any vendor’s roadmap, and the audit calendar may not let you. User access reviews are a standard part of SOX IT general controls testing, and an agent with access to a financial system is, functionally, a user. Auditors will start asking how those agents are reviewed.

1. Give every agent its own identity. No shared service accounts, no reuse of a developer’s credentials.
2. Name a human sponsor for each one, and make sponsorship part of the leaver process so it transfers automatically.
3. Separate delegated from autonomous access, with different policies and clearly marked logs.
4. Grant access per tool, not per agent. When a connector is added, the identity system should see a new permission, not a configuration change.
5. Include agents in access reviews on the same cycle as the systems they touch.
6. Define retirement. An agent unused for a set period is disabled, then deleted, with its credentials revoked.

The bottom line

HENNGE’s gateway is a year away and its non-human identity platform further still. The announcement’s value is the framing. When a company can run with two directors and a team of agents, it is obvious that agents need identities, sponsors and lifecycles of their own. In ordinary enterprises the same is true, just less visible. The question of who answers for an agent’s actions, which we raised in our analysis of Copilot Autopilot, starts with being able to say which agent did what.