Half our users are not people

Our pricing agent adjusts a listing at three in the morning. Who did that? Not the agent, which is not an accountable entity. Not the person who configured it last March, whose session ended six months ago. Not the merchant account generically, or every agent shares one identity and the audit log says nothing. Answering that properly is what separates an access model that holds at 2.8 million agent requests a day from one that collapses the first time a merchant asks why their margin moved.

Publish7 runs AI agents for online retailers. They write and optimise product listings, watch inventory, adjust pricing, and handle the routine end of customer support - across Amazon, Shopify, WooCommerce and BigCommerce, around the clock, without a human in the loop for most of it.

Today that is 2.8 million API requests a day from automated agents, across 1,247 merchants running 4,892 storefronts. The overwhelming majority of authenticated activity on our platform is not a person.

That last fact is the whole engineering problem. "Without a human in the loop" means something that is not a person is making authenticated calls against a merchant's live storefront, moving real prices on real listings. The identity question that raises does not have a clean answer in most authentication systems, because most authentication systems were designed on the assumption that a session belongs to a human being who logged in.

Key Takeaways

• 1,247 merchants, 4,892 storefronts, 2.8 million+ agent API requests a day. Most authenticated activity on our platform is machine, not human.
• Standard B2B access models assume a session belongs to a human who logged in. That assumption breaks the moment an autonomous process acts on someone else's behalf.
• An agent must be a first-class principal with its own identity, not a service account wearing the permissions of whoever configured it.
• Humans authenticate interactively; agents authenticate with the OAuth 2.0 client credentials flow and hold scoped tokens narrower than any human's.
• Building it in-house was honestly estimated at 16 to 20 weeks, on a system whose failure mode is a breach rather than a bug. We were in production in 12 days.
• Merchant trust in an autonomous system is mostly a question about permissions, and your identity model answers it whether you designed one deliberately or not.

Why the standard model does not fit

Think about what a normal B2B SaaS access model assumes. A person signs in. They get a session. The session carries their permissions. Everything the system does after that is attributable to them, and when they leave the company you delete their account and the story ends.

Now put an agent in it. Our pricing agent adjusts a listing at three in the morning. Who did that?

Not the agent - an agent is not a legal or accountable entity, and "the AI did it" is not an answer you can give a merchant whose margin just moved. Not the person who configured the agent last March, whose session ended six months ago and who may not work there any more. The merchant's account, generically? Then every agent on the platform shares one identity, you cannot scope what any of them can touch, and your audit log says nothing useful.

The honest answer is that the agent is a first-class principal with its own identity, acting on behalf of a merchant under an explicitly granted and explicitly bounded authority - and that its permissions are not simply inherited from whoever set it up. That distinction sounds academic. It is not. It determines whether you can answer "what is this agent allowed to do, and who said so" without reading code.

The other three problems, which are less interesting but not optional

Merchants are not one store. A serious retailer runs between 5 and 20 storefronts, often across different marketplaces, sometimes as genuinely separate businesses with separate staff. They need to be isolated from each other - an agent scoped to one storefront must not be able to touch another, and a specialist hired for one marketplace should not see the rest.

Teams are not flat. A store owner, an operations manager, a specialist who only works one marketplace, a support agent who should read but never write. Four roles minimum, and the permission boundaries between them are the whole point.

Marketplaces have their own rules. When you integrate with large marketplaces at the API level, their platform requirements dictate parts of your authentication and audit posture. That is not a design choice you get to make.

We were going to build this. The estimate stopped us.

We planned to build it ourselves, and we stopped when we did the honest estimate - not of the happy path, which is a couple of weeks, but of the whole thing: multi-tenant isolation you can actually defend, a role model that survives contact with real customers, credential rotation, audit logging that satisfies a marketplace review, and the security work that any of that deserves.

Sixteen to twenty weeks. Four to five months of engineering, on a system where the failure mode is a breach rather than a bug, at a company whose differentiation is supposed to be the agents themselves.

We built it on SSOJet instead, and were in production across all merchant accounts in 12 days.

The architecture:

Workspaces as the isolation boundary. Each merchant account holds storefronts as separate workspaces with independent authentication boundaries. This maps directly onto how merchants already think - they do not experience their stores as one system, and neither does our permission model.

Two kinds of principal, one model. Humans authenticate interactively. Agents authenticate with the OAuth 2.0 client credentials flow and hold scoped tokens of their own. This is the important decision in the whole architecture and it is worth stating plainly: an agent does not borrow a human's session. It has credentials, it has a scope, and that scope is narrower than any human's. Our pricing agent can adjust prices on the storefronts it was granted and can do nothing else - it cannot read customer support conversations, it cannot touch another merchant, and it cannot escalate by virtue of the person who created it being an admin.

Roles that describe the job. Store Owner (full access), Manager (operations only), Marketplace Specialist (platform-specific), Support Agent (read-only) - and AI Agent as its own role type rather than a human role that a machine happens to be using. Modelling the agent as its own kind of principal, rather than as a service account wearing a person's permissions, is what makes the audit log readable afterwards.

Automated credential rotation on a 90-day cycle, with advance notification, because an agent that runs continuously has no natural moment to re-authenticate and a long-lived static credential is the thing you least want to be holding. Getting rotation right for a process that must not stop is fiddlier than it sounds - the overlap window is the whole trick.

Audit logging over everything. Every authentication event, human and machine. This started as a compliance requirement and became the tool we reach for first when a merchant asks why something changed.

What it holds up under

2.8 million requests a day is the number I would stress, because it is the one that would have frightened me most about a homegrown implementation. Agent traffic does not look like human traffic. It is sustained, it is bursty in ways that correlate across merchants when a marketplace changes something, and it does not politely back off. Whatever you build has to hold up under a load profile that nothing in your product's history prepared you for.

What it bought us, beyond the engineering

The engineering answer is that we did not spend a quarter building identity infrastructure and we do not maintain it now. Fine, expected, not very interesting.

The more useful answer is what it did to conversations with merchants. When a retailer is deciding whether to let an autonomous system touch their pricing, the questions are not about our AI. They are about control: what exactly can it do, what can it not do, who can change that, and can I see what it did. Having real answers - a scoped credential per agent, a role model you can show someone, an audit trail per storefront - turns out to be a bigger part of the sales conversation than the model quality everyone assumes is the differentiator. The 4.7/5.0 our customers give us on access control is, I think, mostly a rating of how legible we made it.

Trust in an autonomous system is mostly a question about permissions, and it gets answered by your identity model whether you designed one deliberately or not.

If you are building agents that act for someone else

One thing, and it is the thing I would go back and tell myself:

Give the agent its own identity from the start. The tempting shortcut is to let agents run under the credentials of the user who configured them. It works immediately and it is very hard to undo, because by the time you need to answer "what is this agent allowed to do" - and you will, either from a customer or from a marketplace's security review - the answer is tangled up with what some human was allowed to do eighteen months ago. Separating them later means re-deriving intent you never wrote down.

Machine identity is not a feature you add when someone asks for it. It is a decision you make on day one, usually without noticing.

About the numbers in this post

Every figure here is Publish7's own operational data: request volumes and merchant and storefront counts from our own telemetry, uptime from our monitoring, and the 4.7 out of 5.0 access-control score from our customer satisfaction survey. The 12-day figure is elapsed time from starting the integration to running in production across all merchant accounts.

The 16 to 20 week comparison is our own internal estimate of building the equivalent in-house, not a measured outcome. We did not build it, so it cannot be verified. We include it because it is the number the decision was actually made on.

No third-party benchmark is quoted and none is implied.

Disclosure: Publish7 pays for and runs SSOJet in production for human and machine authentication. This post is our account of that project. We were not paid to write it, and SSOJet has published their own version of the same story.

Frequently asked questions

Why do AI agents need their own identity instead of using a user's session?

Because attribution, scoping and revocation all break otherwise. A borrowed session inherits its owner's full permissions, so an agent configured by an admin becomes an admin, which is a scope nobody chose. It also expires or disappears when that person leaves, and your audit log records the human rather than the process that acted. A dedicated principal lets you state exactly what an agent may do, independently of who created it.

How should an autonomous agent authenticate?

We use the OAuth 2.0 client credentials flow, which is designed for exactly this: a client authenticating as itself rather than on behalf of a signed-in user. The agent holds its own credential and receives a scoped token. The interactive flows built for humans assume a browser and a person to redirect, neither of which exists at three in the morning.

How do you rotate credentials for an agent that never stops running?

With an overlap window. Both the old and new credentials have to be valid simultaneously, long enough that a continuously running process picks up the new one without a failed request, and short enough that the old one is not effectively permanent. We rotate on a 90-day cycle with advance notification. Rotation for a process with no natural re-authentication moment is meaningfully harder than for a human login, and it is the part most in-house implementations postpone.

Should an AI agent be a role, or a different kind of principal?

A different kind of principal, with its own role type. If an agent is modelled as a human role that a machine happens to be using, every downstream question - audit attribution, scope, lifecycle, rotation - inherits assumptions written for people. Making it a distinct principal type is what keeps the audit log readable a year later.

How does agent traffic differ from human traffic?

It is sustained rather than diurnal, it is bursty in ways that correlate across tenants when an upstream marketplace changes something, and it does not back off politely under load. Capacity planning modelled on human usage will not describe it. This was the single biggest risk we saw in building identity infrastructure ourselves: not correctness, but behaviour under a load profile we had no history with.

How do you isolate merchants who run many storefronts?

Each storefront is a separate workspace with an independent authentication boundary inside the merchant account. That mirrors how merchants already think. A retailer running 5 to 20 storefronts does not experience them as one system, sometimes runs them as separate businesses with separate staff, and expects an agent or specialist scoped to one to be unable to reach another.

Conclusion

Most of the authenticated activity on our platform is not a person, and that single fact invalidates the assumption underneath most access control: that a session belongs to a human who logged in.

Making agents first-class principals with their own scoped credentials was not a compliance exercise. It is what lets us answer a merchant's real question - what can this thing do, and what can it not do - with a specific answer rather than a reassurance. That turned out to matter more commercially than anything about the models themselves.

If you are building agents that act on someone else's behalf, the identity decision is already made in your codebase, whether or not anyone made it deliberately. It is much cheaper to make it on purpose now than to re-derive it later.

Publish7 uses SSOJet for human and machine authentication. Their version of this story is here.