Daylite is the runtime enforcement and verifiable audit layer for AI agents in regulated enterprises. It is a self-hosted Rust binary that sits at the MCP tool-call boundary. It checks each agent action against policy before the action runs and decides whether it executes, then writes a tamper-evident, cryptographically signed record of what was requested, what policy decided, and what actually ran. It deploys in your VPC, on-prem, or in an air-gapped network.

How is Daylite different from Vanta, Drata, Credo AI, or OneTrust?

Those tools document and score policy. They map it to frameworks and produce reports, and they sit out-of-band from the running agent, so they cannot block a non-compliant tool-call. Daylite enforces policy at the tool-call boundary at runtime and produces cryptographic proof of what the agent actually did. Keep your governance tool for documentation. Daylite sits beneath it.

What does 'built on FIPS-validated cryptography' mean?

Daylite runs its cryptography through AWS-LC, a FIPS 140-3 validated cryptographic library. Daylite itself is not product-certified under CMVP, and we do not claim a CMVP certificate. Commercial enterprise procurement under SOC 2, HIPAA, and DORA accepts library-level validation. FedRAMP High and certain DoD contracts require product-level CMVP, which is on the roadmap.

How does an auditor use the evidence?

Your team runs one command to export the record. The auditor verifies the hash-chain offline with the verify tool, confirms no entry was changed after it was written, and reviews the decisions. The format is open, so there is no lock-in on the evidence itself, and no trust in Daylite is required to check it.

Where does Daylite run, and where does the data go?

Daylite is self-hosted and air-gap capable. It runs in your VPC, on-prem, or in a disconnected network. Data never leaves your environment. That disqualifies cloud-only governance tools in banking and defense, and it is why Daylite fits where they cannot.

How long does Daylite take to deploy?

Minutes. Docker ships today. Run the container, point your agents at the MCP proxy, and the policy gate and the hash-chain audit are live. A Helm chart for Kubernetes is on the roadmap.

July 30, 2026 · 8 min read

Shared service accounts vs per-user credentials for AI agents: the security review question you'll fail

Every agent product starts the same way. You create one service account, give it the permissions the demo needs, and put its key in an environment variable. It works, it ships, and six months later a security reviewer asks one question: "When your agent writes to our system, whose identity does it use?"

If the honest answer is "one shared service account for everything," you are about to lose weeks. This is among the most commonly failed questions in AI vendor reviews, and unlike most of them, it fails on architecture, not on paperwork. Here is why reviewers treat it as disqualifying, what they accept, and how to migrate without rewriting your product.

Why the shared account fails the review

Attribution breaks.Every action in the customer's downstream systems shows the same actor. When something goes wrong, and the whole point of a review is planning for when something goes wrong, nobody can say which agent did it, which task it belonged to, or which human request triggered it. The investigation dead-ends at your service account.

Least privilege breaks. A shared account needs the union of every permission any agent might ever use. Your invoice-drafting agent and your data-export agent hold the same rights. A prompt injection against the weakest agent yields the permissions of the strongest.

Revocation breaks. Rotating or revoking the shared credential takes down every agent at once, so in practice nobody rotates it. Reviewers know this pattern and probe for credential age directly.

Segregation of duties breaks. Controls that assume different actors approve and execute stop meaning anything when both actors resolve to the same account. Bank reviewers, who answer to examiners on exactly this point, ask the question in its hardest form. See what bank and credit-union reviewers ask for how it lands there.

What reviewers ask, in their words

The question appears in several forms across questionnaires. From the 21 in the AI security question bank, these are the shapes it takes: Can you attribute each agent action to a distinct identity? What is the scope and lifetime of each credential an agent holds? Can the model read the raw secret? How do you revoke a single agent without affecting others? Does the agent act with the invoking user's permissions or its own?

Notice that none of these mention service accounts. Reviewers ask for the properties, then check whether your architecture can have them. A shared account cannot, so the answer writes itself once they hear the design.

The architecture that passes

Four properties, in rising order of effort:

Distinct identity per agent. Each agent authenticates as itself. Downstream logs show which agent acted, and one agent can be revoked alone.
Scope per task, not per product. The credential issued for a task carries only the permissions that task needs.
Short-lived, issued at runtime. Tokens minted per task and expiring in minutes turn a leaked credential from a standing breach into a narrow window.
The model never sees the secret. Credentials injected at a boundary outside the model's context cannot be exfiltrated by prompt injection, no matter what the agent is talked into.

When the agent acts for a specific human, add delegation: the agent operates under the user's permissions as a ceiling, while remaining distinguishable from the user in every log line.

Migrating without a rewrite

Teams avoid this fix because it looks like it touches every integration. The workable path is to move identity out of the agents and into the boundary they already pass through. First, inventory what each agent actually calls, from logs, not from memory. Second, split the shared account into per-agent principals with narrowed scopes, which requires no agent code changes if a gateway holds the credentials. Third, move token issuance to runtime, per task. Fourth, write the remaining gaps into your review answers as current state, compensating control, and date.

This is the pattern Daylite implements at the MCP tool-call boundary: agents hold phantom references instead of raw keys, real credentials are injected at the proxy edge with per-tool scope, and every issuance and use lands in a hash-chained, signed audit record. The point stands independently of any product: identity at the boundary is cheaper than identity refactored into every agent.

FAQ

Why do reviewers care whether agents share a service account?

Because attribution collapses. When every agent action arrives at the database or the CRM as the same identity, nobody can say which agent, which task, or which human's request caused a given change. Least privilege collapses with it, since the shared account must hold the union of every permission any agent might need.

Is a shared service account ever acceptable in a review?

As a documented interim state, sometimes. Reviewers accept a gap written as current state, compensating control, and date. A scoped read-only shared account with full logging and a dated migration plan reads very differently from the same account discovered on a follow-up call after you claimed per-agent identity.

What does per-agent identity actually look like?

Each agent, and ideally each task, acts under its own identity with its own credential: distinct API principals, short-lived tokens issued per task, scope limited to the tools that task needs. Downstream systems then see who acted, logs attribute actions correctly, and revoking one agent does not break the rest.

Should agents impersonate the human user instead?

Acting on behalf of a user with the user's delegated, scoped permissions is often the right ceiling: the agent can never do more than the human who invoked it. But keep the agent distinguishable in logs. An agent that is indistinguishable from its human breaks investigations in the other direction, because nobody can tell which actions were the model's.

Which frameworks does this map to?

In NIST SP 800-53 terms it is the AC family, access enforcement and least privilege, plus the AU family for attribution in audit records. The OWASP agentic risk lists call the failure identity and privilege abuse. Bank reviewers ask it as a traceability question, without citing any framework at all.

Want to know which of these questions you would pass today? Run the free 2-minute readiness checker, or let the AI Security Review Kit build the full answer pack from a 30-minute intake.

Written by Dmitrii Karataev. Twenty years in infrastructure and security. Corrections welcome: hello@daylite.ai.