Agency governance for AI tools: audit logs, roles, and API keys

Sooner or later a client asks the uncomfortable question. A tracked prompt set changed, a competitor was removed from a dashboard, or a report went out with different numbers than the week before. Who did that, and when? In a small agency the honest answer used to be "probably someone on the team." That was never a good answer, and it gets worse when software agents can also change settings.

Marketing platforms now accept changes from several directions: a person in the dashboard, a script through an API, a connected tool through MCP, or an assistant working in a chat panel. The question stops being "which of us did it" and becomes "which of us, or which of our automations, did it." This post is how we handle that on client programs.

The risk in plain terms

Three failure modes show up repeatedly in agency work.

Silent scope changes. A prompt gets deleted or a competitor gets swapped. The charts move, and nobody can explain why. A trend comparison across that date is no longer valid, but nobody knows the date.

Over-shared keys. An API key created for a reporting script ends up in a shared document, a contractor's laptop, or a client handover. It outlives the person who made it.

Access that never shrinks. A freelancer helps with a pitch, then the engagement ends. Their access stays. Six months later nobody remembers why they are on the account.

None of these needs a sophisticated attacker. They are housekeeping failures, and housekeeping is something you can fix with a few rules.

Rules that work without any tool

We keep four rules on every engagement, written in the project folder.

1. Least access by default. Team members get the lowest role that lets them do their job. Most people who read reports do not need to edit anything.
2. One key per purpose. Each integration gets its own key, named for what it does and who owns it, and scoped as narrowly as the platform allows. When the purpose ends, the key is deleted the same day.
3. A change log of our own. When we change a prompt set, a competitor list, or a brand definition, we write the date and reason in the client record. It is slow, and it is also the thing that saves a bad conversation.
4. A quarterly access review. Every three months we list who has access to each client workspace and remove anyone who no longer needs it.

If your platform gives you nothing else, these four rules cover most of the exposure.

What the platform side now offers

The Promptwatch changelog describes several controls that line up with these rules. On September 30, 2026 it added an Audit log under organisation settings. It lists every change made in the organisation, who or what made it, and when, whether the change came from the dashboard, the API, MCP clients, or Agent Chat. You can filter by person, source, or outcome, or search by action. The changelog states that the audit log is available to organisation owners on Business plans and higher. Our fact sheet lists it on Business, Agency Scale, and Enterprise.

That plan boundary affects how we scope agency work. A lower agency tier does not include the audit log, so on those tiers rule three, our own change log, carries the whole load. We tell clients which situation they are in.

A later changelog entry adds two smaller points that matter for rule two. Project viewers no longer see API key secrets or the API keys page, and the team member list is visible only to organisation owners. Both reduce accidental exposure: a client stakeholder with view access cannot copy a key they have no business holding. The platform also supports scoped API keys at project, organisation, and read-only levels, which is the tool for the one-key-per-purpose rule.

How we apply this by role

We split users into three groups.

Owners are a small number of senior people at the agency, plus the client's named account owner where the client wants one. Owners can see the audit log, manage keys, and change membership. We keep this group to the minimum.

Editors are the analysts and strategists doing the work. They can change prompts, topics, and dashboards, and all changes show up under their names.

Viewers are client stakeholders and junior reviewers. They read dashboards and receive reports.

Keys follow the same logic. A reporting script gets a read-only key. A script that creates pitch projects or adds prompts gets a key scoped to the project it works on. We never reuse a personal key for automation.

Where Promptwatch fits

Promptwatch is the platform we run client programs on, and the audit log is a good example of why we recommend reading plan matrices before a pitch rather than after. The control that answers "who or what changed this" is there, including for changes made by Agent Chat or MCP, but it starts on Business and Agency Scale. If a client expects a tamper-evident trail, we tell them which plan gives it. Visit promptwatch.com for the plan details and check the current matrix before you quote.

The log tells you what happened. It does not tell you whether the change was right. We still review the owner-level changes in a weekly check, and we look at agent-made changes more closely than human ones in the first month of using any new automation, because automated edits tend to be bulk edits.

How to handle the client question

When the client asks who changed something, the answer should take five minutes. Open the log, filter by date and action, and read out what you see. If the change came from an agent working on our instructions, say so. If it came from a client user, say that too, without blame.

Clients rarely mind that things change. They mind not being told, or being told "we are not sure." A clear record and a short quarterly access review do more for trust than any promise about being careful.

A starter checklist

• Name an owner for every client workspace and key.
• Use read-only keys wherever a script only reads.
• Review access quarterly and remove stale users.
• Keep your own change log even if the platform has an audit log.
• Confirm which plan includes audit logging before you promise it.
• Treat agent-made edits as bulk edits until the pattern proves otherwise.