DEV Community: Auth By Example

A better spec won't stop a coding agent from deploying to prod

Auth By Example — Wed, 28 Oct 2026 16:07:58 +0000

I work at Permit, and this is from a post our CEO wrote on zero standing permissions for coding and automation agents. We sell authorization, so keep the bias in mind. The ideas work in any stack.

Specs help accuracy. They don't limit access.

A detailed PRD makes an agent's output better, with fewer retries and fewer surprise changes. Say the spec reads "update deployment config in staging only". If the agent holds a token that can deploy to production, the spec is just a request. Whatever the credential allows is what can happen.

The post suggests using the spec as input to a permission check. Pull the intended resource, action, environment and risk level out of it, and have a policy decide whether a given tool call fits.

Start with nothing

Zero standing permissions means the agent holds no lasting authority between tasks. When someone approves a task (a ticket, a PR comment, a chat command), the runtime works out what it needs, sorts each tool call by risk (read, write, deploy, notify, money, sensitive data) and asks a policy whether it's allowed. If it is, it mints a short-lived credential for only those actions. Going from staging to production needs another approval. High-risk steps get checked again when they happen, and the grant is revoked if the task drifts or times out.

Credential options, roughly from worst to best

Static API keys: easy to set up, but long-lived, hard to rotate, over-scoped, and hard to trace back to a person.
Service accounts for the agent: kept apart from human identities, which helps, but still risky when the permissions are broad and permanent. Fine for narrow jobs like indexing docs or scheduled read-only checks.
OAuth delegated access: good when the action happens in a user's context and you want a grant you can revoke. Scopes are often coarse.
Runtime policy plus short-lived tokens: least privilege per task, at the cost of building or buying the policy layer.

What the audit log should answer

Which person approved this deploy, which agent and version ran it, under which policy version, with which token (scopes, issue time, expiry), and what changed? The post's schema also has the ticket or spec reference, the MCP tool and resource, the policy decision and its reason, the environment, and timestamps for request, decision and execution, so you can rebuild the order of events afterward.

It also notes that Cursor and Claude MCP setups shouldn't differ much here. Either way: no copied human tokens, a policy check per tool call, and credentials minted per task.

Full post: https://www.permit.io/blog/zero-standing-permissions-coding-automation-agents?utm_source=devto&utm_medium=social&utm_campaign=zero-standing-permissions-coding-automation-agents&utm_content=authbyexample-article

Do your coding agents hold standing tokens today? If you moved to per-task credentials, I'd like to know what broke first.

Shared agent memory needs a permission check on every read

Auth By Example — Wed, 28 Oct 2026 16:07:35 +0000

I work at Permit. One of our AI engineers wrote a post about shared memory for coding agents, and since we sell authorization, read the framing with that in mind. I think the problem it describes holds up either way.

Shared team memory for coding agents is handy. One agent figures out a repo's quirks, and the next person's agent gets that context for free. Those entries can also hold architecture details, internal file paths, hints about credentials and old decisions. Once memory outlives a session and spans users, every retrieval is an agent being handed access to that knowledge on someone's behalf.

The revocation gap

Say someone loses access to a repo at 2:00 PM. If memory access was decided at onboarding, or got cached high in the stack, their agent can still pull what it learned about that repo at 2:01 PM. Reads and writes need a check at the time they happen, against current state.

Redaction and encryption don't decide who reads what

Redaction strips known-sensitive bits before they're stored. It helps, but it depends on patterns and misses secrets that don't look like secrets. Encryption protects the data at rest and in transit. Neither one says whether this person should see this plaintext once it's decrypted. That's an authorization decision, and it has to be made per request.

Modeling it as relationships

The post uses ReBAC. A human operates or delegates to an agent, the agent works in a team context, the team belongs to a project, and memory entries hang off the project, optionally scoped by repo and path. A rule then reads like this: the agent can read an entry if it acts for an active project member, the team can see the repo, and the current task scope matches the entry's tags. Remove one relationship and everything downstream of it stops resolving.

Whose permissions does the memory server use?

Picking just one source causes trouble. Inheriting the human's permissions overexposes memory when agents juggle several tasks or async jobs. Project-level inheritance is too broad for repos with mixed sensitivity. Agent-level inheritance lets long-lived agents build up standing privilege. The post lands on the intersection of the human's rights, project policy and the agent's scope for the current task, all evaluated at decision time.

What to log

For each retrieval decision the post wants human, agent, project, query, memory entry, decision and outcome, plus a timestamp, the policy version and a correlation ID. Without those you can't explain why an agent saw something, or whether a revocation took effect in time.

The full post also has an FAQ on team vs. project scoping and on Claude Code and Codex team memory: https://www.permit.io/blog/shared-agent-memory-is-a-permissions-problem?utm_source=devto&utm_medium=social&utm_campaign=shared-agent-memory-is-a-permissions-problem&utm_content=authbyexample-article

If you run shared memory for agents today, where does your check sit: inside the memory server, or in front of it?

EN 18286 is out. What would an auditor ask about your AI agents?

Auth By Example — Wed, 28 Oct 2026 16:07:13 +0000

I work at Permit. Our VP of R&D wrote up what EN 18286:2026 means for teams shipping AI agents. We sell authorization, so read this with that bias in mind.

What the standard is

EN 18286:2026 is the first harmonised standard under the EU AI Act. It turns the Article 17 quality management system requirements for providers of high-risk AI systems into processes an auditor can check. CEN approved it on 12 July 2026, and its reference was published in the Official Journal around October 14. Following it gives you a presumption of conformity for the Article 17 requirements it covers. It's meant to sit on top of a QMS you may already have, like ISO/IEC 42001 or ISO 9001.

It doesn't mention AI agents, authorization or MCP anywhere. It also only applies to high-risk systems, and most agents won't be classified that way. I still think agent teams should read about it, because the processes it asks for (risk management, human oversight, data quality, cybersecurity) are the same things enterprise security reviews already ask about agents.

The questions it leads to

Once an agent can call tools, change data or send messages, those processes turn into pretty concrete questions:

What is the agent allowed to do, and where is that written down?
How do you manage risk when it acts for a user?
Who approves the sensitive actions before they run?
What record shows it stayed inside policy?

Why "it uses the user's token" is a weak answer

A lot of agents authenticate as the user and run with everything that user can do. If an auditor asks which actions the agent was authorized to take, the honest answer is all of them. Why was a given action allowed? Because the user could have done it. What oversight happened first? None was required.

What the post suggests instead

Give the agent its own identity and credentials, even when it acts for a user, so the delegation is explicit.
Run a policy check before every tool call, looking at the user, the agent, the resource, the action and the context.
Block sensitive actions until a human approves, and store the approval with the decision.
Log the authorization decision along with the tool output: who acted, for whom, on what, under which policy version, with what result.
Put scope in policy. A prompt telling the agent to stay away from something can't enforce it.
If agent A calls agent B, check and log each hop.

The post also covers where Permit fits. It says plainly that the standard doesn't prescribe any vendor, and that EN 18286 covers Article 17 only, so it won't make you AI Act compliant on its own.

Full write-up: https://www.permit.io/blog/en-18286-qms-eu-ai-act-agent-authorization?utm_source=devto&utm_medium=social&utm_campaign=en-18286&utm_content=authbyexample-article

Is anyone here getting asked about EN 18286 yet, either by a notified body or by enterprise customers?

Moving off Oso Cloud? Sort your Polar rules into three piles first

Auth By Example — Sun, 18 Oct 2026 08:14:23 +0000

Oso Cloud was acquired by Tiny, and the deal closed on October 1. Oso says Cloud keeps running as usual, and most of the team has joined Temporal. If production authorization runs through it, it is reasonable to want a migration plan on paper before you actually need one. This is the order I would work in.

Sort your Polar into three piles

Most policies mix three patterns, and each one moves differently.

Role blocks, like "read" if "viewer"; inside a resource block. That is plain RBAC, and it maps to roles and permissions in almost any system.
Roles derived through relations, like "reader" if "member" on "organization";. That is ReBAC. Whatever you move to needs relationship tuples and role derivation, so a simple roles table will not cover it.
Attribute rules, like allow(user: User, "view", doc: Document) if user.clearance_level >= doc.classification;. These become conditions in Rego, Cedar or whatever you pick, and the attributes have to be available when the check runs.

Count what lands in each pile. A codebase that is mostly role blocks moves quickly. One built on nested relations needs real modeling time first.

Get your facts out

The rules are only half of it. Every has_role and has_relation fact you have sent to Oso Cloud is data your app depends on. Find every place your code writes facts and make sure you can rebuild all of them from your own database. If you cannot, fix that before anything else, because it is the hardest piece to reconstruct later.

Find your list queries

Single checks like authorize(user, "read", doc) port easily. "Show me every document this user can read" is harder. Look for every list call and every spot where you use local authorization to filter in SQL, then confirm the new system can answer the same question at your data size.

Run both side by side

Before you cut over, call the new engine next to Oso on real traffic. Keep enforcing Oso's answer and log every disagreement. The mismatches usually point straight at a derived role or an attribute you mapped wrong.

I work at Permit, so I am biased about where you end up. We wrote up how each of these Polar patterns maps to Permit, with code for each: https://www.permit.io/blog/migrate-from-oso-to-permit?utm_source=devto&utm_medium=social&utm_campaign=oso-migration&utm_content=gabriel-post

Sorting your Polar policies before you pick an Oso alternative

Auth By Example — Sat, 17 Oct 2026 11:56:37 +0000

I am on the marketing team at Permit. A lot of teams are re-reading their Oso setup this month, and sorting the Polar policies tends to get skipped at the start.

Oso Cloud was acquired by Tiny, with the deal closing on Oct 1, and Oso says Cloud will continue to operate as usual. Most of the Oso team joined Temporal. Nothing in that announcement means a team has to move today.

If you are planning a move, export your Polar policies first and sort each rule before you evaluate vendors. Role grants inside a resource block are RBAC. A role that comes from a relation is ReBAC, for example a repo reader who inherits from an org member, and copying that rule across also means syncing the relationship data behind it. Conditions on user or resource attributes are ABAC. For those you need to decide whether the attributes get synced ahead of time or sent with each check.

List filtering deserves its own line in the inventory. A single check and a query for every document a user can read do not fail in the same way.

We published a longer mapping with Permit code examples for each pattern: https://www.permit.io/blog/migrate-from-oso-to-permit?utm_source=devto&utm_medium=social&utm_campaign=oso-migration

Whatever target you pick, run the old and new systems side by side for a while and log where they disagree. Cut over after the disagreements reach zero.

An offline sync queue can apply edits after the user lost write access

Auth By Example — Fri, 16 Oct 2026 08:14:08 +0000

Mobile and desktop clients often queue mutations while the network is down. The app checks edit permission when the user taps Save, stores the change locally, and later POSTs the batch when connectivity returns. That later POST usually trusts the queued payload and the still-valid session cookie. It does not ask whether the user may still edit that record.

Jordan drafts a contract amendment on a plane. While they are offline, an admin removes Jordan from the deal room. The flight lands, the client reconnects, and the queued update succeeds. The audit log shows Jordan as the editor hours after their access ended.

Authorize every queued mutation again at apply time, against the live policy for that user and record. If the check fails, leave the item in a conflict or rejected state instead of writing it. Do the same for conflict-resolution merges that run on the server, because a merge is still a write. Expire or discard queued writes when the session that created them is revoked.

To test it, grant edit on a record, put the client offline, queue an update, revoke edit (or remove the user from the space), bring the client online, and confirm the queued write is rejected and the record is unchanged.

Moving a project to another org can leave the old org's API keys working

Auth By Example — Fri, 16 Oct 2026 06:40:27 +0000

A lot of SaaS products let you move a project from one organization to another, often after an acquisition or when a team splits off. The move updates project.org_id and copies the members over. The API keys and deploy tokens created inside the project stay attached to project_id, and the auth middleware only checks that the key belongs to that project.

So the agency that built a project for a client hands it over, and the agency's CI token is still pushing to it a month later. Nobody in the new org created that token. It also doesn't show up in their org-level key list, because it was issued under the old org.

Treat the transfer as a permission change for every credential tied to the project. Either revoke project-scoped keys during the move, or store an issued_by_org_id on each key and reject the key when it no longer matches the project's current org. Right after the transfer, show the new org's admins any keys that survived and who created them, so they can decide what to keep.

To test it, create a project key in org A, transfer the project to org B, and call the API with the old key. You want a 401 or 403 back. If the call goes through, the old org still has a way in.

Your trash folder can list deleted records the user was never allowed to open

Auth By Example — Fri, 16 Oct 2026 05:11:02 +0000

Most apps check access on the live record and stop caring once it's deleted. The trash page runs its own query, something like deleted_at IS NOT NULL AND workspace_id = ?, and shows every row it finds. Titles and owners show up for anyone who can open the trash.

So a member of a shared workspace opens the bin and sees "Q4 reorg plan", a doc that sat in a private folder they never had access to. Some apps also let them hit Restore, and the doc comes back with them listed as the last editor.

Run the same read check on the trash list that you run on the normal list, using the permissions the record had right before it was deleted. That means keeping the parent folder ID on the deleted row so the check still has something to look at. Treat restore as its own check: the user needs edit rights on the record and write access to the folder it's going back into. If you'd rather keep permanent delete for admins only, that's fine, but the trash list itself should never show more than the user could see before.

To test it, put a doc in a private folder as one user, delete it, then open the trash as a second user who isn't in that folder. If the title shows up, your trash view skips the permission check.

How Oso Polar policies map to RBAC, ReBAC and ABAC if you're planning a move

Auth By Example — Thu, 15 Oct 2026 08:21:58 +0000

Tiny Ltd completed its acquisition of Oso Cloud on October 1, 2026, and most of the Oso team is joining Temporal. Oso says Oso Cloud will keep operating as usual. If your production authorization runs on it, this is still a good moment to write down what your Polar policies actually do, while you have working knowledge of them.

Most Polar files mix three patterns. Sorting them first makes any target easier to pick:

Role grants inside a resource block, like "push" if "admin";. This is plain RBAC: a resource, its actions, and roles that hold permissions.
Role derivation through a relation, like "reader" if "member" on "organization";. In ReBAC terms you need the relation defined on the resource type, plus the actual relationship data (repo-1 belongs to org acme) synced from your app.
Attribute conditions in allow rules, such as user.department == "engineering" and doc.classification != "restricted". Those attributes either get synced ahead of time or passed in with each check.

The call site changes least. oso.authorize(user, "read", document) becomes one check with user, action and resource, plus a tenant if you're multi-tenant. List filtering and "which resources can this user see" queries need their own mapping, so inventory those endpoints early.

One more thing to look for: the open-source Oso library (the standalone Polar engine) was deprecated in December 2023, in case an older service still depends on it.

Disclosure: I work at Permit.io. My colleague Ze'ev Manilovich wrote the full guide, with Permit SDK examples for each pattern and a step-by-step migration plan:

https://www.permit.io/blog/migrate-from-oso-to-permit?utm_source=devto&utm_medium=social&utm_campaign=oso-migration&utm_content=authbyexample-article

An out-of-office delegate can keep approving after the owner is back

Auth By Example — Thu, 15 Oct 2026 07:45:53 +0000

Many apps let a manager hand approvals to a colleague while they're on leave. The usual build copies the manager's approver grants onto the delegate, shows an end date in the UI, and leaves cleanup to a nightly job. The approve endpoint then only checks whether the caller has approver rights.

That fails in a few places. The cleanup job fails or runs late, so the delegate keeps approving days after the manager is back. Halfway through the leave the manager loses a budget line, but the delegate's copied grants still cover it. Or the manager leaves the company, and the delegate keeps everything that was copied.

Keep the grants on the manager. Store the delegation as its own record: who acts, for whom, which actions, start and end. On every request, confirm the delegation is active right now, the action is in its scope, and the manager could still do it today. Log both names on the decision so the audit trail shows who clicked and whose authority they used.

To test it, set a delegation to end in five minutes, wait, and call the approve endpoint as the delegate. Then, with a fresh delegation still active, remove one approval right from the manager and try again as the delegate. Both calls should fail.

A share link should stop working when the person who made it loses access

Auth By Example — Thu, 15 Oct 2026 05:14:27 +0000

Most apps that let you share a record by link store the link as a random token plus the record ID. Someone opens the link, the server finds the token and shows the record. The app saves who created the link, but nothing checks that person again.

This breaks when the creator's own access changes. A contractor shares a project doc with a client, then the contract ends and an admin removes them from the workspace. The link they made still opens the doc. The same thing happens when someone moves to another team and loses a folder, or when a doc is moved into a restricted space after the link was made.

Treat the link as acting for its creator. When someone opens it, check that the creator can still read the record right now, and that the link's level (view, comment or edit) is no higher than what the creator has today. If either check fails, return the same error you'd return for an unknown token, so whoever holds the link can't tell the record still exists.

When you deactivate a user, list the links they created and show them to the admin doing it. Some are fine to keep, like a public pricing sheet, and the admin can hand those to someone who still has access.

To test it, create a link as a regular user, remove that user from the workspace, then open the link in a private window. If the record loads, your links don't check their creator.

A new group with an old group's name can inherit everything the old one could access

Auth By Example — Wed, 14 Oct 2026 10:46:05 +0000

Plenty of apps store access grants against a group name that comes from the identity provider: engineering-leads can edit the roadmap, finance can see invoices. When someone deletes the group in Okta or Entra ID, the app usually never hears about it, so the grant rows stay in its database.

Months later somebody creates a new group and happens to pick the same name. Maybe it's a different team, or a contractor group someone named carelessly. The next time its members sign in, their token carries groups: ["finance"], the app matches on the string, and they can open every invoice the old finance group could.

Key grants on the IdP's immutable group ID (the object ID in Entra ID, the group id in Okta) and keep the display name only for showing in the UI. When a directory sync or SCIM push reports a group as deleted, delete its grants in the same transaction. If you can't get delete events, run a periodic job that compares the groups you hold grants for against the IdP and flags the ones that no longer exist.

To test it, grant a test group access to one record, delete the group in your IdP, create a new group with the same name, add a user to it and sign in as that user. If they can open the record, your app is trusting the name.