Agentic AI security is a credential problem, not a prompting problem
An AI agent that can write to your CRM, ERP or database is a production actor. The interesting failures are not jailbreaks — they are ordinary, successful API calls made for the wrong reason, with no diff, no evidence and no signature behind them.
This page is the threat model we build against, the seven controls that actually reduce blast radius, and the anti-patterns we see most often. The through-line: keep the write credential out of the reasoning system.
Indirect prompt injection
Untrusted text in an email, ticket or web page instructs the agent. The model complies, and the instruction reaches your record layer as an ordinary API call.
MITIGATION → HUMAN GATE ON WRITEOver-broad credentials
An admin token issued once for convenience. Every later task inherits the full blast radius, including tasks nobody scoped for it.
MITIGATION → AGENT HOLDS NO WRITE TOKENSilent misinterpretation
No failure, no exception. The agent read "end of Q3" and picked the wrong fiscal calendar. Correct syntax, wrong fact.
MITIGATION → EVIDENCE REQUIRED PER FIELDUnbounded batch actions
One reasoning step produces four hundred updates. The intent was plausible; the volume is the incident.
MITIGATION → RATE + SCOPE POLICYNon-repudiation gap
After the fact there is no diff, no reason, no signature — so nobody can say who changed the record, or on what basis.
MITIGATION → HASH-CHAINED AUDIT TRAILTime-of-check / time-of-use
A change approved on Monday merges on Wednesday, against a record that moved in between — or became immutable.
MITIGATION → RE-EVALUATE AT MERGE TIMESeparate the proposer from the writer
The component that reasons must not be the component that commits. An agent emits a change set; a narrow merge worker — the only holder of the write credential — applies approved changes. Injection then buys the attacker a proposal, not a fact.
Least privilege, per system of record
Read-only tokens on the read path. One scoped write credential per system, held by the merge worker, never by the model, the console session, or a developer laptop.
Policy as deterministic code
Do not ask a model to enforce its own guardrails. Field-level rules, schema validation, immutability windows and value bounds run as code, produce a verdict per change, and fail closed.
Evidence attached to every field
Each proposed value cites its source: message ID, document span, query result. A reviewer verifies the citation instead of trusting the summary, and an auditor can re-derive the value later.
Human approval where impact is real
Route by risk, not by taste. Low-impact, well-evidenced, in-policy changes can auto-merge; revenue, identity, permissions and financial fields require a named human, per change.
Append-only, hash-chained audit
Before/after snapshot, evidence references, policy verdict, approver and timestamp — each entry committing to the previous one, so deletion or backdating is detectable rather than invisible.
Shadow mode before any authority
Run the agent read-only for a period and measure the approval rate on real proposals. Grant auto-merge only to the policy classes the data supports, and revoke on drift.
Controls that only look like controls
agent no write credential read path read-only token, per system reviewer user session, no record token merge worker sole writer, scoped per system every merge appends: diff · evidence · verdict · approver entry N commits to entry N-1 (sha256)
Put these controls in front of your agent, not inside its prompt.
ActionsLedger is the review layer: policy as code, evidence per field, human approval, and a hash-chained trail — with the write credential held by the merge worker alone.