Monitoring non-human identities by default
November 9, 2025 · 5 min read
Non-human identities are not intruders. They are authorized participants in your infrastructure. Service accounts, API clients, AI agents, automation scripts, scheduled jobs, and machine-to-machine integrations all operate with legitimate credentials and permissions granted by your organization. They access data, modify records, trigger workflows, and make decisions on behalf of your teams.
The risk is not that they are unauthorized. The risk is that they misbehave. An AI agent that starts hallucinating and modifying records it should not touch. A service account whose credentials are stolen and used by an attacker operating from inside the infrastructure. An automation script that malfunctions and overwrites data at scale. An API client that begins accessing resources outside its intended scope. These are not perimeter threats. They happen inside the application, with valid credentials, and they look like normal operations until the damage is done.
Monitoring should be in place before a non-human identity gets access, not added after something goes wrong.
Monitoring NHI behavior with tirreno
tirreno analyzes non-human identity behavior using the same event pipeline, rule engine, and trust scoring that it applies to all accounts. Every event from an NHI is sent to the tirreno sensor with the same parameters: user identifier, IP address, URL, timestamp, event type, and any relevant metadata. tirreno builds a behavioral profile for each identity and evaluates every event against the rules.
NHI accounts accumulate trust scores over time. An API client that operates from the same IP, accesses the same endpoints, at consistent intervals, builds a stable behavioral baseline. When that same client suddenly begins accessing different resources, from a different IP, at unusual times, the trust score drops. When the deviation is large enough, the account surfaces in the review queue or triggers automatic suspension.
The behavioral signals that matter for NHI have their own baselines. A scheduled job running at 3 AM may be perfectly normal. A data synchronization service accessing hundreds of records per minute may be expected. The rules need to reflect what is normal for each type of identity, which is why the ability to write custom rules matters.
Custom rules for your own workflows
Every organization uses non-human identities differently. A generic rule set cannot anticipate the specific workflows, access patterns, and expected behaviors of your API clients, service accounts, and AI agents. tirreno's custom rule system lets you define what normal looks like for your NHI and what constitutes a deviation worth flagging.
Custom rules define conditions based on event data, account attributes, IP signals, device data, and session patterns. You decide what combination of signals indicates that a non-human identity is operating outside its expected boundaries.
For example, you might write a rule that flags an API client accessing endpoints it has never accessed before. Or a rule that detects a service account whose request volume exceeds its historical average by a defined threshold. Or a rule that alerts when an AI agent modifies records in a data category that is outside its designated scope. The rules are specific to your application because only you know what each non-human identity is supposed to do.
Field audit trail for NHI actions
When a non-human identity modifies data, the field audit trail captures exactly what changed. Every field modification sent through the API is recorded with the old value, the new value, the identity that made the change, the IP address, and the timestamp. This applies equally to changes made by any account, human or machine.
For AI agents, this is particularly important. If an agent begins modifying records based on flawed logic or corrupted input, the audit trail provides the evidence needed to understand what happened, when it started, and how far the damage spread. Without this record, reconstructing the scope of a malfunctioning agent's actions across thousands of records is extremely difficult.
The audit trail also serves as the accountability layer for NHI operations. When a regulator or auditor asks who modified a specific record, the answer may be a service account or an AI agent rather than a person. The trail documents the modification with the same precision regardless of the actor.
Why NHI monitoring should run on-premise
Non-human identity monitoring involves some of the most sensitive operational data in your environment. Which service accounts exist, what they access, how they behave, which API clients connect from which infrastructure, and what patterns their operations follow. This data describes the internal architecture and operational rhythms of your systems.
Sending it to a SaaS monitoring vendor means that vendor builds a detailed map of your internal operations on their infrastructure. For organizations in regulated sectors, or those handling sensitive data, this is a data exposure that goes beyond personal data protection. It is operational intelligence.
tirreno runs on-premise. The behavioral profiles, trust scores, audit trails, and detection records for your non-human identities stay in your database. The enrichment API provides IP intelligence inward, but none of your NHI behavioral data flows outward. When you need to investigate an incident involving a compromised service account or a malfunctioning AI agent, the evidence is in your own systems, queryable on your own terms.
Open-source detection logic means you can inspect exactly how each NHI is being evaluated. When a legitimate automation is incorrectly flagged, you can identify the contributing rules and adjust. When a new type of NHI is deployed in your environment, you can write rules that reflect its expected behavior from day one rather than waiting for a vendor to update their model.
A practical integration plan
Monitoring non-human identities starts with knowing what you have. Most organizations undercount their NHI population because service accounts, API clients, and automation scripts are created by different teams at different times with no central registry.
1. Inventory your non-human identities. Catalog service account, API client, AI agent, automation script, scheduled job, and machine-to-machine integration that interacts with your applications. Include who owns each identity, when it was created, and whether it is still actively needed. Dormant NHI credentials are among the most common entry points for attackers.
2. Map each identity's intended scope. For every NHI, document what it is supposed to do: which endpoints it accesses, which data it reads or modifies, what schedule it operates on, and which IP ranges it should connect from. This is the behavioral contract, the definition of normal that monitoring will compare against.
3. Assign a risk level based on capability. An API client with read-only access to non-sensitive data is low risk. A service account that can modify financial records or delete production data is critical. An AI agent with write access to customer-facing systems carries both operational and reputational risk. This classification determines how aggressively you monitor and how quickly you respond to deviations.
4. Start with the highest-privilege identities. Prioritize the identities that can do the most damage: service accounts with broad write access, AI agents that act autonomously, and API clients connected to sensitive data. Instrument these first, then expand coverage to lower-risk identities as your baselines mature.
5. Deploy tirreno and begin building baselines. Send NHI events to the tirreno sensor with the same parameters you use for any account: identity, IP, URL, timestamp, event type. Apply the insider_threat and api_protection presets as a starting configuration, then write custom rules that reflect each identity's intended scope from step 2. The baselines will take shape over the first weeks of collection. After that, deviations become visible.
Start monitoring today
Non-human identities are the fastest-growing attack surface in modern applications. Every day they operate without behavioral monitoring is a day of baseline data you don't have when an incident occurs.
Open source, download at tirreno.com/download. The developer guide covers API integration, event types, custom rules, and the blacklist endpoint.