Access Is Not Permission: Why an API Key Is Not Your Safety Layer

An API key decides what an AI can technically do, not what it should do. Many keys can read, write, send and delete, and some APIs offer no read-only scope at all. So the real safety layer sits elsewhere: the account's access level, an allow list in code, and a named person approving consequential actions.

This is general information, not security or legal advice.

Why is an API key not a safety layer?

An API key is a credential, not a policy. It proves who is calling and opens whatever the vendor attached to it, often far more than one job needs. If the key can delete records, an AI holding it can delete records. The only thing stopping it is whatever sits between the AI and the call.

Most connections today run on the key's full reach. A team connects a tool, the connector asks for broad scopes, someone clicks approve, and the AI inherits everything. Nothing about that is malicious. It is simply how most integrations were designed, for people who use software carefully, not agents that act quickly.

According to OWASP's guidance on excessive agency, damaging actions follow from "unexpected, ambiguous or manipulated outputs from an LLM, regardless of what is causing the LLM to malfunction." The cause does not matter. A wide key turns any mistake into a wide one.

What is the difference between access and permission?

Access is what a credential can technically do in a system. Permission is the business's decision about what an AI may do there, for which job, and with whose approval. The two are set by different people for different reasons, and the gap between them is where most AI incidents start.

The principle is old. NIST defines least privilege as restricting access "to the minimum necessary to accomplish assigned tasks". Agents make it urgent, because they can use all of their access in seconds. The guide to AI agent permissions covers how to scope each agent.

What if an API has no read-only scope?

Then the lock moves to the account. Connect through a user or role whose access level is read only, and the key inherits that ceiling. Where even that is not possible, put code between the AI and the tool that permits only named actions. A written rule alone is not enough for a credential that can do everything.

Some major APIs work this way. According to Google's documentation, the Google Ads API has a single OAuth scope, and the page mentions no read-only alternative. Whatever an account login can do, a connected tool can do too.

So the account's role becomes the control that holds. A login with read-only access to an ad account cannot change a budget, whatever the AI is told. That is a stronger guarantee than any instruction.

Arguments can matter as much as tools. One API call might create a draft or publish live, depending on a single field. A rule that only names tools cannot see that difference, so code must check the arguments.

Why do deny lists fail as tools are added?

A deny list blocks the actions you know are dangerous and permits everything else. That works until the vendor adds a new tool, which arrives allowed because nobody listed it. An allow list does the opposite: it permits only named actions and refuses the rest, including tools that do not exist yet.

Connectors change constantly. MCP servers gain new tools with each release, and a deny list written last quarter knows nothing about them. OWASP's MCP Top 10 names the pattern as scope creep: permissions "often expand over time, granting agents excessive capabilities".

Failing closed is the right failure. When an allow list meets something new, nothing happens until a person looks.

What does a layered lock look like?

Four layers, each covering what the others miss. The account's access level sets the ceiling. An allow list in code permits only named actions, checking arguments where they matter. Written rules state what the AI may do and why. And a named person approves anything that sends, publishes, spends or changes records in bulk.

1. Access level. Read only by default, raised per tool only when a job needs it.
2. Allow list in code. Named actions pass; everything else is refused.
3. Written rules. What the AI may do in each system, and who approved that.
4. Approval. A person takes the final step on anything consequential.

Instructions alone are not a layer. Anthropic's Claude Code documentation says its instruction files are treated "as context, not enforced configuration", and points to a hook that runs code before a tool call as the way to block an action outright.

The same documentation notes that its settings skip any MCP rule written to match a tool's parameters. A check on arguments therefore needs code, which is why hooks exist.

How do you check the lock holds?

Test it the way an attacker or a mistake would. Ask the AI to do something the rules forbid and confirm it is refused by code, not by the model's good manners. Review every connection quarterly: what the key can reach, what the allow list permits, and whether new vendor tools appeared.

Keep a register of every connection, its access level, its allow list and who approved it. Check logs for refused calls, because a pattern of refusals shows where a job needs a deliberate decision. The guide to MCP security covers the audit in more depth.

Skein starts every connection read only and grants write access one tool and one action at a time, with a named person approving anything published, sent or spent; the shared knowledge layer page explains the permission model. That suits a business connecting AI to its CRM, ad accounts or website. A team using AI only on pasted text has little to lock down yet.

Frequently asked questions

Is an API key enough to keep AI safe?

No. A key proves identity and unlocks whatever the vendor attached to it, often reading, writing, sending and deleting. Safety comes from what sits around it: a limited account access level, an allow list in code that permits only named actions, written rules and a person approving consequential actions.

What is the difference between access and permission for AI?

Access is what a credential technically allows in a system. Permission is the business's decision about which actions an AI may take, for which job, with whose approval. Access is set by the vendor and the connection; permission is set deliberately by the business and recorded.

What if a tool has no read-only option?

Connect through an account or role whose own access level is read only, so the key inherits that limit. Where that is not possible, place code between the AI and the tool that allows only named actions and refuses everything else. A written instruction alone will not hold.

Why are allow lists safer than deny lists?

A deny list blocks known risky actions and permits everything else, so new tools a vendor adds arrive allowed. An allow list permits only approved actions and refuses the rest, including tools that appear later. It fails closed, which means a mistake results in nothing happening rather than something unexpected.

Can I just tell the AI not to do something?

Instructions help, but they are guidance, not enforcement. A model can misread them, or follow instructions hidden in content it reads. Anything that must never happen, such as sending, publishing or deleting without approval, should be blocked by access levels or code, with a person approving the action.

Related reading