# What an AI Agent in Your IT Stack Should Never Be Able to Do

_Menni Alashvili · 2026-09-22_

**Categories:** AI Service Desk, ESM Strategy

The architecture behind an AI agent that can reset passwords and change group membership: what it can touch, what stops it, and what it writes down. Not the pitch.

If you're a security lead being asked to approve an AI agent inside your ESM or ITSM platform, one that can reset passwords, change group membership, and act inside your MDM, you already know the demo isn't the interesting part. The interesting part is what happens when the agent is wrong, is fed a malicious input, or is asked to do something it shouldn't. And whether anyone can tell afterward.

Most vendor conversations about agentic AI don't survive that question. The answer is either a reassurance ("we take security seriously") or a change of subject back to the time savings. I spent over a decade in cybersecurity before coming to Harmony, building products that had to pass exactly this kind of review. I've sat through enough of those conversations to know that a vague answer to "what can this thing do if it's wrong" usually decides the outcome.

So this post is the architecture, not the pitch: what the agent can touch, what it can't, who decides what it's allowed to do, and what stops it when something goes wrong. If you need the compliance baseline (certifications, attestations, and the frameworks we align to), that lives on our [Trust Center](https://trust.harmony.io/). This is about the part an audit doesn't tell you.

## The Core Design Principle: The Model Never Executes

The language model has no connection to your identity provider, MDM, or any other production system. It can't construct an API call, hold a credential, or take an action on its own judgment.

Its job is narrower than that. It works out what the employee is asking for, and matches that to one of a fixed set of workflows your team reviewed and approved before it ever ran, whether you built them yourselves or adopted ours. The model decides _what_ is being requested. _How_ it happens was decided in advance, by you.

Two properties make that boundary hold.

First, the model never invents an object. Every application, group, device, or user it references is resolved against Harmony's system of record, a continuously synced mirror of your IdP, MDM, and HRIS. A request for something that doesn't exist there isn't approximated; it fails. And what _does_ exist is filtered by eligibility rules you define, so an employee can't request, or even see, objects they're not entitled to.

Second, the requester's identity comes from the authenticated session, never from the text of the request. "Me" always means the person who logged in. Requests on behalf of someone else are a separate path: they always route through approval, and higher-risk actions aren't available on behalf of another user at all.

This is also what lets the workflows enforce checks the model alone couldn't be trusted to make. When an employee asks for access to Salesforce, the workflow queries current entitlements before doing anything. If they already have it, the request stops there, and the agent explains why, to avoid unnecessary actions or duplicate assignments.

## Access: Narrow by Default, Decided by You

When people talk about what an agent can access, two questions get blurred together: what the agent can do to its own privileges, and what it can do to everyone else's.

The first answer is simple. Nothing. Every integration runs on scoped credentials defined per application and granted by an admin in advance, using OAuth wherever the platform supports it. There is no path by which the agent requests, expands, or grants itself a scope. Remove a permission and the workflow that depended on it stops working; the product doesn't route around it.

The second answer is where the real design work is. The agent _can_ change things for users: password resets, group membership in your IdP, device actions in your MDM. Those are the actions that make it useful, and they're the ones that should worry you. So they're constrained at three layers: **scope**, meaning what a workflow may touch; **eligibility**, meaning who may request what; and **approval**, meaning what waits for a human before it runs.

Scope is an allowlist you define, and it's worth treating as a security decision rather than a setup step. Privileged groups belong outside it or behind approval, and Harmony will not make that call for you. New groups synced from your directory arrive non-writable; nothing becomes actionable until an admin opts it in.

Who may request what is set by eligibility rules drawn from your directory.

And which requests execute immediately versus wait for a human is a policy set per action.

Access grants can also be time-boxed. Where you enable it, membership granted through a workflow expires automatically rather than accumulating: the difference between an agent that hands out access and one that lends it. It's your configuration decision, and standing access is still supported where you need it.

Knowledge follows the same model. Two employees asking the same question get answers drawn only from what each is entitled to see, because retrieval runs against a permissions-aware index synced continuously from sources such as Confluence and SharePoint. One caveat worth knowing: "continuously" means a sync interval, not real time.

## Control and Visibility

Narrow access limits what an agent can touch. Guardrails control what it's allowed to do with that access, and they're defined when the workflow is built, not bolted on afterward. Every agent carries configurable approval and escalation policies: sensitive actions route to a human before they execute, not after.

If something still goes wrong, you don't need us to stop it. Every action the agent takes goes through an integration, and any integration can be disconnected with a single click in the admin console. No integration, no action. And because each integration is a credential you issued in your own systems, revoking it at the source cuts the agent off regardless of anything on Harmony's side.

Prompt injection deserves a direct answer, because anyone telling you it's solved is wrong. A sufficiently clever input, whether typed by a user or planted in a document the agent reads, can still influence what the model thinks is being asked. What it can't do is change what happens next. The model can only reach pre-approved workflows; each object it names must resolve against your real directory and pass your eligibility rules; the requester is fixed by the session; and anything sensitive still stops at a human. Injection can steer the model. It has nowhere to steer it _to_.

Every action, whether executed or escalated, writes to an audit log exportable to your SIEM. Each entry records who asked, what the model understood the request to be, which workflow ran, what it touched, and who approved it. Changes to workflows, allowlists, and policies are logged the same way, because those are the actions that actually alter what the agent can do. Guardrails stop something before it happens. The log tells you exactly what did.

## Data Handling

Harmony doesn't train on your data, and neither does the model provider. Inference runs through Amazon Bedrock, which doesn't store prompts or use them for training. Retention is split by data class: the audit record (tickets, changes, approvals, comments) is kept for as long as your obligations require, and some of our customers need ten years. Conversation transcripts and model inputs are a separate class with their own shorter retention window.

Because the system of record mirrors your directory, we're holding a copy of who your people are and what they can reach. That's a data asset and we treat it as one: isolated per tenant, encrypted in transit and at rest, in the region you specify. Credentials and tokens live in a dedicated secrets manager, never in workflow logic. Systems that can't be exposed to the internet connect through a zero-trust connector, with its credentials held the same way.

Limitations, stated plainly: no BYOK, no bring-your-own-model, and no air-gapped deployment today. If air-gap is a hard requirement, this isn't the right fit yet, and it's better you know that now than after a pilot. The rest of the detail (isolation model, model versions, sync intervals, residency options) is the stuff of a proper review, and we'll walk through it with you.

## The Bar We're Setting

Every point in this post traces back to one decision: build the architecture a security team would design themselves, not the one that's fastest to ship. Narrow access. A human in the loop before anything sensitive happens. A full record of what ran. Limitations we tell you about upfront, not ones you discover mid-pilot.

ESM isn't new. Agentic ESM is, and the industry is racing to ship the agent before answering how it's controlled. We think that ordering is backwards. The bar for adding autonomy to systems this sensitive isn't "can it act." It's "can it be trusted to act, and can you prove it."

If that's the standard you hold your vendors to, we'd like the chance to earn it.