Read-Only and Logged: Security Requirements for AI Agents on Your Admin Platforms

The situation

The requests started the way they always do: someone built a proof of concept that summarizes tickets, pulls device health and drafts a reply, and it worked well enough that people wanted it pointed at production. In an MSP, production means the remote management platform that can run scripts on every endpoint, the documentation platform that stores client credentials, and the ticketing system that holds every customer conversation.

Security had two options. Say no and watch the agents get built anyway with a technician’s personal API key pasted into a config file, or publish a short, clear set of requirements and make the safe path the fast one. We went with the second. This post is the generalized version of that handout, with the vendor specifics stripped out, because the pattern applies to any agent you connect to any admin platform.

Why an agent is different

The first instinct is to treat an agent like any other integration: create an API user, scope it, done. That misses what changed. The permissions haven’t changed, but who’s pulling the trigger has.

The input trust row is the one that matters most. Prompt injection, and specifically the indirect kind where the instructions arrive inside data the agent retrieves, is catalogued as MITRE ATLAS AML.T0051.001 and still sits at the top of the OWASP Top 10 for LLM Applications 2026 as LLM01. In an MSP, anyone who can email a support address can put text in front of your agent.

A useful mental model for leadership: treat the agent like an untrusted junior tech with admin credentials and no judgment about what it reads.

The real risk: blast radius

When we walked through what a single leaked or misused credential could reach on each platform, two scenarios stood out as deal-breakers:

1. Unattended code execution across the fleet. Remote management platforms run jobs as SYSTEM or root. An over-granted key that can launch a job, or change the variables a script reads at runtime, is a mass-deployment path across every client.
2. Bulk credential theft. Documentation platforms hold client admin passwords, network diagrams and runbooks. A key with password access is every client’s credentials plus a map of where to use them.

Behind those sat a set of high-rated risks that apply to any platform: injected instructions in returned content, long-lived keys leaking from agent configs, one key spanning every client tenant with no per-client isolation, an untrusted third-party agent server or proxy capturing keys, and a runaway loop exhausting a shared API rate limit and getting your egress IP blocked, which breaks every other integration on that account.

OWASP calls the underlying condition Excessive Agency: an LLM with more functionality, permissions or autonomy than the task needs. It climbed from LLM06 in the 2025 list to LLM03 in the 2026 edition, driven by agentic deployments. Prompt injection gets the model to try something it shouldn’t. Excessive agency decides whether that attempt does any damage. You can’t fully stop the first, so you constrain the second.

Requirement 1: Read-only

The rule is simple: agents read and recommend; people make changes. No create, update or delete calls, for every client and every environment, including the pilot.

Enforce it twice

Don’t trust a single layer. Enforce read-only at the vendor and again at a gateway you control, so a mistake in one is caught by the other.

At the vendor: create a dedicated API identity for each agent with view-only permissions. In practice, platforms differ a lot here:

• Some offer role-based API users where an “inquire only” role is enforced by the vendor. That’s the clean case.
• Some have no built-in read-only level, so you build a custom permission set with every item at view and the lowest script or job execution level available.
• Some issue API keys that are read/write by design. There, the gateway is your only write barrier, so lock the key to the gateway’s egress IP and turn off any password or secrets access on it.

None of the platforms we reviewed could scope a single key to one client, so client isolation has to live in the gateway too.

At the gateway: the agent never talks to vendor APIs directly. It calls tools on a gateway (in most current stacks, an MCP server or proxy) that enforces what the vendors can’t:

The user filter is the one that’s easy to miss. The agent’s vendor identity can see every in-scope client, but the person driving the session usually can’t. Without a check on the human’s own entitlements, a tech scoped to three clients can ask the agent about a fourth. The joint CISA/NSA agentic guidance calls this the confused deputy: a lower-privileged party getting a trusted agent to do what it couldn’t do directly. NIST SP 800-228 makes the same point for APIs generally: every call carries two identities, the calling service and the user it acts for, and both need authorizing.

Tier the tools

Read-only gets easier to defend when people can see where everything else goes:

The agent can propose a change. It never holds a credential that can make one, and it never decides for itself when a human needs to approve something. The design makes that call.

Handle credentials like they matter

• One dedicated identity per agent, per platform. Never a technician’s personal account, never an admin role, never a key shared across agents or environments.
• Vendor secrets usually show once at creation. Paste them straight into your secrets vault, never into a ticket or chat as a staging step.
• The gateway reads keys at runtime using its own managed identity. Keys never appear in agent config files, environment files, repos, prompts or tool arguments.
• No token passthrough: the gateway never hands vendor tokens back to the agent. The MCP security best practices call token passthrough an explicitly forbidden anti-pattern for the same reasons.
• Prefer short-lived, federated credentials wherever a platform supports them. Where it only offers static keys, rotate on a fixed schedule (we use 90 days), revoke immediately when an agent is retired, and separate duties: the person who creates the key doesn’t build the agent.

Know what you’re plugging in and where the data goes

Three pre-deployment questions sit outside the API permissions entirely, and they’re the ones most often skipped:

• Where does client data go? Everything the agent reads is sent to a model provider. Before go-live, confirm the provider’s retention and training terms, where the data is processed, and that the contract covers the data in scope. For health data that means a business associate agreement under HIPAA; for CUI it means a provider that meets the FedRAMP Moderate equivalency in DFARS 252.204-7012. If the answer is no, that client is out of scope, whatever the permissions look like.
• What code is in the path? Third-party agent servers, plugins and connectors are supply chain. Use only vetted sources, pin versions, record a hash of each approved tool definition and re-review when it changes, so a tool can’t quietly change behaviour after approval (a “rug pull”). Never point an agent at a server you can’t inspect that holds your vendor credentials.
• Can you say what the agent is made of? Keep an inventory record per agent: owner, model and provider, connectors and their versions, the tools in its catalogue and the clients in scope. The UK AI Cyber Security Code of Practice asks for an asset inventory (Principle 5), and the joint agentic guidance goes further with approved tool allowlists and an SBOM-style record for agentic workflows.

Start small. Pilot against an internal test tenant with seeded data, then one low-risk use case, and widen scope only after the logs show the agent behaving as expected. That incremental rollout is the primary structural recommendation in the joint CISA/NSA agentic AI guidance.

Requirement 2: Logged

No logs, no go-live. Every tool call, allowed or blocked, produces one structured event in the SIEM, tied to a human.

What every event needs

{
  "ts": "2026-01-01T12:00:00Z",
  "agent": "ticket-triage-v2",
  "session": "a91f...",
  "user": "tech@example.com",
  "tool": "tickets.get",
  "method": "GET",
  "endpoint": "/tickets/{id}",
  "client": "<client-id>",
  "decision": "allowed",
  "rule": "ro-allowlist-v3",
  "status": 200,
  "records": 1,
  "params_hash": "sha256:..."
}

The user field is the one teams forget most and the one incident response needs most. Without it, every action traces back to a shared service account and attribution during an investigation is guesswork. That’s the same accountability requirement as NIST SP 800-171 3.3.2 (AU.L2-3.3.2 in CMMC): actions must be uniquely traceable to individual users.

Never put secrets in any log: API keys, tokens or password values. Keep the SIEM event lean as well: hash the parameters so you can correlate calls without copying client data into the SIEM.

That doesn’t mean throwing away the context. Current guidance expects you to be able to reconstruct why an agent did something, not just what it called. Keep the full session record (prompt, tool calls, tool output and the agent’s response) in a separate, encrypted, access-controlled store under the same retention as the SIEM, keyed by session. The SIEM event tells you which session to pull; the transcript tells you what the agent was looking at when it made the call.

Pipeline and retention

• Gateway events, plus each vendor’s own activity or audit logs and the vault’s secret-access events, all land in the SIEM. The vendor logs are an independent record, not something the agent or gateway reports about itself, which is what the joint agentic guidance asks for when it recommends cross-checking agent activity against separate monitoring.
• Delivery within about a minute; retention matched to the strictest compliance requirement in scope.
• Append-only and SIEM-managed: builders can read their logs but can’t delete them.
• Clocks in UTC, synced to an authoritative time source.
• If the gateway goes quiet for a set window, that’s an alert, not a relief.

Publish the detections

Telling builders what trips an alert up front is part of not being a blocker:

Verification

Every agent goes through the same gate before it touches client data, with evidence attached to the intake request.

First, prove a write is refused. Run this through the gateway with the agent’s own session, and run the equivalent call against each vendor API with the agent’s vendor credential:

# Attempt a write through the gateway; it should be refused and raise a High alert
# $token = the agent's own gateway session token (never a vendor key)
$uri  = "https://<gateway>/tools/tickets"
$body = @{ summary = "agent-write-test" } | ConvertTo-Json
try {
    Invoke-RestMethod -Method Post -Uri $uri -Body $body -ContentType "application/json" `
        -Headers @{ Authorization = "Bearer $token" }
    "FAIL: write was accepted"
} catch {
    if ($_.Exception.Response) {
        # Expect 403 (or 405) and a matching blocked event in the SIEM
        "Status: {0}" -f [int]$_.Exception.Response.StatusCode
    } else {
        "No HTTP response: $($_.Exception.Message)"   # network/TLS error, not a pass
    }
}

Then the rest of the checklist:

How this lines up with published guidance

None of this is new invention. It’s the existing least privilege, logging and supply chain controls, applied to a new kind of principal. The joint CISA/NSA/Five Eyes guidance, Careful Adoption of Agentic AI Services, groups agentic risk into five categories, which makes a handy coverage check for a first review:

The rest of the government guidance points the same way:

NIST’s SP 800-53 control overlays for AI agent systems are still in development, so for now the mapping runs through the existing controls listed under Caveats.

What this post doesn’t cover: multi-agent designs, where one agent’s output becomes another’s input, and agents with persistent memory. Both add risk categories (see the OWASP Top 10 for Agentic Applications) and deserve their own review.

Caveats

• Vendor permission models drift. Settings get renamed and new endpoints ship. Confirm the current options in each admin console before relying on them, and rerun the write test after vendor updates.
• Read-only is not harmless. A read-only agent can still leak data through its own output or be steered into a misleading recommendation. Redaction, tenant filtering and the human in the loop for Tier 1 changes carry that weight.
• Not every read is a GET. Some vendor search and reporting APIs use POST for queries. Allow those as specific method and endpoint pairs in the catalogue rather than loosening the method rule, and confirm at the vendor that the identity can’t write anyway.
• Compliance evidence. The access and logging controls map cleanly to least privilege (NIST SP 800-171 3.1.5), audit logging and user accountability (3.3.1, 3.3.2), audit protection (3.3.8) and time sync (3.3.7). The same artifacts serve SOC 2 and HIPAA audit-control evidence. Retention values have to match each client’s requirement, not one internal default.
• People over-trust fluent answers. A recommendation that reads well isn’t verified. Tell technicians that agent output is a starting point, that they never paste secrets into a session, and how to report an answer that looks steered.
• Plan the exit. Retiring an agent means revoking its keys, removing its tools from the catalogue, closing its inventory record and disposing of its transcripts on the retention schedule. The UK Code treats end of life as its own principle for a reason.
• Risk acceptance. If a team needs an agent that writes, it doesn’t get a write-capable key. It gets a Tier 2 design review, a named owner and a documented risk acceptance, with a human approval step on every action.

Key takeaways

1. An AI agent is a new privileged user that reads untrusted text at machine speed. Threat-model it like one.
2. You can’t fully prevent prompt injection, so limit what a successful injection can do: read-only, enforced at the vendor and again at the gateway, with per-client and per-user scoping in the gateway because vendors rarely offer it.
3. Before the first call, know where client data goes (model provider terms and agreements) and what code sits in the path (pinned, vetted connectors).
4. Every call gets logged with the human behind it, and the session can be replayed. No logs, no go-live.
5. Make the secure path the fast path: a tool catalog, a sandbox, a short checklist and published detections get you more compliant agents than a policy that says no.

References

• CISA, NSA and partners: Careful Adoption of Agentic AI Services (May 2026)
• Canadian Centre for Cyber Security: Careful adoption of agentic AI (web version of the joint guidance)
• NSA AI Security Center: Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation (May 2026)
• NSA, CISA, FBI and partners: Deploying AI Systems Securely (April 2024)
• UK DSIT: AI Cyber Security Code of Practice and implementation guide
• NIST: SP 800-228, Guidelines for API Protection for Cloud-Native Systems
• NIST NCCoE: Accelerating the Adoption of Software and AI Agent Identity and Authorization (concept paper, draft)
• OWASP GenAI Security Project: Top 10 for LLM Applications 2026 (LLM01 Prompt Injection, LLM03 Excessive Agency)
• OWASP GenAI Security Project: Top 10 for Agentic Applications
• MITRE ATLAS: AML.T0051 LLM Prompt Injection and AML.T0051.001 Indirect
• Model Context Protocol: Security Best Practices (token passthrough, confused deputy)
• HHS: Guidance on HIPAA and Cloud Computing
• DFARS: 252.204-7012 Safeguarding Covered Defense Information
• NIST: SP 800-171 Rev. 2, requirements 3.1.5, 3.3.1, 3.3.2, 3.3.7, 3.3.8
• NIST: SP 800-53 Rev. 5, AC-6 Least Privilege, AU-3 Content of Audit Records, AU-9 Protection of Audit Information
• NIST: AI 600-1, Generative AI Profile