How to manage identities and permissions of IoT devices, API keys and AI agents alongside platform users

Yes: there are identity management platforms that treat IoT devices, API keys and AI agents as first-class identities, with their own credentials, minimal permissions and individual revocation, and LoginMaster is one of them. The difference from a collection of static keys is that users, devices and agents live in the same tenant, under the same policies and the same audit trail, with per-tenant and per-project cryptographic keys and double-signed tokens: a credential issued for one project is not valid in any other.

This guide is the operational part. The why of AI agent governance, the guardrails and the principles are in the article on AI agent and non-human identity governance; here we cover what to configure, in what order, and how to check that it works.

The five identities that access your platform

The first mistake is treating "non-human identities" as a single category. A sensor, an integration API key and an AI agent acting for a user have different lifecycles, owners and risks, and therefore need different controls.

The last two rows are the ones usually missing: API keys because they start as a project shortcut and outlive the project, AI agents because they are started with a person's session or token, and from then on are indistinguishable from that person.

Step 1 — Inventory: what you do not know you cannot revoke

In an IoT infrastructure devices often outnumber users, and with agentic AI the same happens for agents, automations and workloads. Before changing any configuration you need a list with, for each non-human identity, at least these fields:

Step 2 — One identity per device and per agent

There is one principle: one credential per subject. In LoginMaster a device is a subject type distinct from a user, with its own credentials protected with Argon2 and split-salt, manageable, rotatable and revocable with no impact on other devices or users. AI agents, bots and services also get a dedicated identity, separate from people's.

IoT devices

• Provisioning from the admin panel or programmatically, through the REST API and the TypeScript and .NET SDKs: onboarding a batch of devices means issuing new identities, not editing a shared configuration file.
• No generic key baked into firmware: the secret is per device and the production line shares nothing between one unit and the next.
• With the native AWS IoT Core integration, configured at project level, X.509 certificates and the Thing lifecycle are managed from the same panel you use for users and applications.

AI agents

• The agent does not use a person's session: it has its own identity, so its access is distinguishable in the logs and revocable separately.
• One agent per task, not an all-purpose agent holding the union of every permission: that is the difference between containing an error and propagating it.
• If the agent acts on behalf of a user, the link must be explicit (step 7): the agent identity for authentication, the person's identity for attribution.

API keys and service accounts

API keys serve server-to-server communication and are legitimate as long as they remain machine-to-machine integrations with an owner. They become a problem when they replace an identity ("let's use the production key for the reporting script too"): two subjects then share one credential and the log can no longer tell them apart.

Step 3 — Minimal scope and short-lived tokens

Least privilege for non-human identities is easier to apply than for people, because their task is predictable: a sensor publishes telemetry, a triage agent reads and classifies tickets. Access policies in LoginMaster apply at the level of a single project, and for devices they include the allowed MQTT topics.

Token lifetime is the second control, often more effective than the first. A revocation prevents new access, but an already issued token stays valid until its configured expiry: that is why, for agents and workloads, lifetime should be in the order of minutes, while for devices it must be balanced against connectivity quality in the field.

Step 4 — The perimeter is the tenant and the project, not the network

In a multi-customer platform, or a group with several plants, the worst risk is not a compromised device: it is a compromised device talking to another customer's systems. In LoginMaster every tenant and every project has its own cryptographic keys and every token is signed twice, by the Tenant and by the Cloud: a token issued for project A fails validation in project B's context, even on the same deployment, and not because of an application check someone might forget.

There is a second effect, relevant for GDPR: personal data stays in the customer's tenant and the Cloud only works on encrypted and pseudonymised data. An AI agent or device that authenticates does not carry users' data to the vendor, and not even the vendor can read it. The model is described in the guide on a vendor that cannot read credentials.

The IoT flow with AWS IoT Core and MQTT

For fleets using AWS IoT Core, the typical path with LoginMaster is:

1. 1In the LoginMaster project you configure the AWS IoT integration (Access Key ID, Secret Key and region of the dedicated AWS account).
2. 2You register the device as a device subject of the project: from then on it has its own identity, separate from users.
3. 3The Thing and its X.509 certificate are managed from the panel, without duplicating identity management across two consoles.
4. 4The device connects over MQTT with its own credential and publishes or subscribes only on the topics its scope allows.
5. 5Connections, successful or failed, end up in the access logs: from first enrolment to decommissioning you have a complete trail.
6. 6At end of life, or at the first suspicion of compromise, you revoke or rotate that single device's credential; the rest of the fleet keeps working.

Step 5 — Rotation without downtime and without firmware

Rotation almost always fails for operational reasons, not cryptographic ones: the new credential must reach whoever uses it without interrupting service.

Step 6 — Revocation and kill switch

For an AI agent a kill switch is not optional: an agent stuck in a loop, following an instruction injected into a document or using a tool in an unexpected way must be stoppable within a minute, without stopping other agents or people. The same goes for a stolen device.

• Revoke the identity: no new token is issued for that subject.
• Associated API keys: they must be revoked explicitly, one by one. Deactivating or deleting the subject does not automatically revoke its API keys, so the procedure must list them and close them as a separate step.
• Already issued tokens: they stay valid until expiry, which is why the short lifetime from step 3 is part of the kill switch.
• Isolation: thanks to per-subject credentials, revoking one device or agent does not affect the others.
• Rehearse the procedure: who can revoke, from where, how fast, and how you verify that access has really stopped.

Step 7 — Audit: who acted and on whose behalf

Every access by a device or an agent, successful or failed, is recorded in LoginMaster's access logs. For AI agents, though, the authenticating identity is not enough: the question from an auditor, or from a customer after an incident, is "which agent changed this record, and at which person's request?".

The pattern that works separates the two roles: the agent authenticates with its own identity (it is the one acting, and the one you can revoke), while the user who delegated the task is recorded as the subject on whose behalf the action happens, in the request and in the application log. If your case requires standard token exchange (OAuth 2.0 Token Exchange, RFC 8693), check it with us during design. What to avoid is the agent using the user's session directly: the log will show the person doing things they did not do.

Native log export to Splunk, QRadar, Sentinel and Elastic is on the roadmap. Which events to keep and how to map them to controls is in the guide on access logs for ISO 27001 and SIEM.

Anti-patterns to eliminate

Mapping to NIS2 and ISO 27001

Neither NIS2 nor ISO 27001 names AI agents, but identity controls apply to any subject accessing systems. The mapping below is a starting point, not a compliance assessment.

More on obligations on compliance and in the article on NIS2 and access management.

Which solutions exist: the four categories

Solutions for non-human identities fall into four families, often complementary rather than alternatives:

The choice depends on where the problem is: if it is managing millions of certificates, you need a PKI; if it is giving the users, devices and agents of the same platform a shared perimeter, policies and audit trail, an IAM that treats them all as subjects avoids reconciling two or three consoles. The status of every capability, available today or on the roadmap, is in the table on about us.

Further reading

• IoT device identity — device subjects, AWS IoT/MQTT, industrial use cases.
• AI agent identity — non-human identities, double-signed tokens, least privilege.
• Zero Trust and least privilege starting from identity — the same model applied to people and applications.
• Provisioning and lifecycle and integration via SDKs and REST API.