Your Agent Shouldn't Hold Your Wallet: AEGIS, a Credential and Policy Layer for Personal AI Agents

Your Agent Shouldn't Hold Your Wallet, or Anything Else of Value for That Matter

AEGIS: Toward a Credential and Policy Layer for Personal AI Agents

Personal AI agents are being adopted in exactly the wrong order. A person meets one of these agents, likes what it can do, and within minutes hands it a credit card, an inbox, and a calendar — standing access to the parts of a life that matter most — before the agent has done a single thing to earn that trust. We think this ordering is backwards, and that the fix is not a smarter agent. It is a layer that sits between the agent and everything it touches, the way a firewall sits between a network and the internet rather than trusting every packet to behave itself.

Convenience is arriving faster than judgment

Consider what a personal agent is now asked to do. Instinct, a consumer agent that reaches a user's credit cards, email, and calendar through nothing more than a text message, has already produced a small, telling catalogue of failures reported in the press this fall:

A flight was canceled before the agent showed the user its cost — an irreversible, financially consequential action taken before the approval step that should have gated it.
Asked only to check restaurant availability, the agent went ahead and booked a table at a venue with a $200 cancellation fee — an action authorized for discovery quietly becoming a commitment, with no separate approval in between.
The agent's own repeated attempts to secure a reservation triggered a temporary lockout on the reservation platform — no single request was improper, but the pattern of activity looked, to that platform, like abuse.

None of these are edge cases dreamed up by a security researcher. They are what a competent, well-intentioned agent does when it has been given a goal and a set of tools and nothing in between to say when a step has gone further than it should.

The pattern is not confined to one vendor. Meta's Muse agent, now capable of completing purchases directly through Shop Pay on Shopify's network, was blocked from shopping on Amazon within the same week — not because of a technical exploit, but because Amazon decided, unilaterally, that it did not trust a third party acting on a customer's behalf inside its own store. Two large platforms, two opposite answers to the same question: should an autonomous agent be allowed to act as if it were the person who authorized it? Neither answer involves anyone asking what the agent is actually allowed to do, transaction by transaction. That is the gap this piece is about.

We tried Muse ourselves. On first launch, it asked for permission to read the entire hard drive — not a folder, not a file type, the whole drive, to use however it later decided it needed to. We declined. If we ever grant that kind of access, it will be on a machine with nothing on it worth losing, not the one we do our banking on — which is itself a fair test of whether an agent has earned the trust it is asking for.

None of this required a villain

It is worth being precise about what kind of failure this is, because the instinct is to reach for better AI — a model that reasons more carefully, or that has been fine-tuned to ‘know better.’ We think that instinct is a category error. An agent that books a table it was only asked to check on has not made a reasoning mistake in any sense a bigger model would fix; it has produced an action that is syntactically valid — the booking API call is well-formed, the credentials are real, nothing crashed — and semantically wrong, because it violates an intention the user never had the chance to state. We have made this argument at length elsewhere, in the context of enterprise AI-agent tool calls: the industry's security tooling is very good at checking whether a call is authorized, and has almost nothing to say about whether the resulting sequence of actions is what anyone actually wanted.

In other words, the missing piece is not intelligence. It is structure: a place where a user's intent is written down once, in advance, and checked against every consequential action before that action is allowed to happen — not after, when the flight is already canceled.

This problem is older than AI, and so is its solution

Enterprise software solved a version of this problem decades ago, long before anyone worried about autonomous agents. A database transaction either satisfies its preconditions and postconditions or it is rolled back; a well-built configuration engine checks that a set of interdependent choices are jointly consistent before it lets a customer commit to an order, rather than discovering the conflict at fulfillment. The idea, in both cases, is the same: state the rules once, as data, and evaluate every proposed change against them mechanically, rather than hoping the system generating the change happens to get it right.

Now apply that idea to a single, deliberately small example. A user tells their agent: “See if there’s a table at 7 tonight.” The rule that should govern this is almost embarrassingly simple — checking availability and committing to a reservation are different actions, and the second one needs a separate yes. State that rule once, as a constraint the agent's proposed action is checked against, and the failure we described earlier cannot happen, regardless of how the agent arrived at its decision to book. Generalize the same idea — a spending cap, a list of vendors that always require approval, a limit on how many times the agent may retry against one external service in a minute — and you have the outline of a real governance layer, built the same way a constraint-based configuration system is built: as explicit, checkable rules, not as a hope that the model has internalized good judgment.

A personal agent should hold a token, not a key

We call this layer Aegis. The idea is straightforward to state even though it takes some care to build: instead of giving a personal agent a real credit card, a real inbox password, or real file access, the user gives those to Aegis, along with a short, plain-language list of hard limits — spending caps, categories that always need explicit approval, actions that are simply off-limits, limits on unattended or repeated activity. The agent is then registered to Aegis rather than handed the underlying credentials directly, and receives only the scoped, temporary access it needs for the task in front of it — a token good for one restaurant, one amount, one evening, rather than a standing key to the user's entire financial life.

Without AEGIS a personal agent holds standing access to credit card, email, calendar and files; with AEGIS each request passes a policy check that issues one scoped token at a time

There is more than one way to hand an agent that scoped access, and the difference is worth spelling out, because it determines what can work today versus what depends on someone else's goodwill:

The strongest version has the agent ask Aegis directly, in real time, for permission before each consequential step. This works cleanly, but only for agents built to cooperate with an outside authority in the first place — realistic for agents built on open, API-first protocols, not guaranteed for a closed consumer app.
A more broadly useful version needs no cooperation at all: the user generates a limited-purpose card, a filtered email address, or a restricted calendar share at Aegis, and simply hands that to the agent as if it were the real thing. The agent never has to know Aegis exists.
Where even that is not possible — an agent reachable only by text message, say, with nothing to integrate against — a hard cap on the payment method itself becomes the fallback: blunter, because it can limit how much but not which vendor or whether approval was properly sequenced, but still a real, working backstop.

Either way, a violation should not simply fail silently. The useful failure mode names exactly which limit was crossed and asks the user, in the moment, whether to proceed — the same discipline we have argued for in AI agents generally: a system that is going to say no should say no specifically, not just refuse and leave the user guessing.

An agent's proposed action is checked against the user's hard limits: within limits a scoped token is issued, outside limits it goes back to the user with the reason

Held to the right standard, this is closer to Plaid than to a password manager

It is tempting to describe Aegis as a password manager for agents, and it is worth resisting that comparison, because it understates the trust being asked for. A password manager holds secrets a user already controls and already understands the risk of losing. Aegis is asking to hold more access than the user would otherwise give an agent directly, on the argument that doing so is actually safer — which is a claim that has to be earned, not assumed, and it is more honestly compared to a service like Plaid: infrastructure a person encounters inside an app they already trust, at the exact moment that app needs to connect to their bank, rather than a destination they go looking for on their own.

We would also rather say this plainly than let a reader discover it later: the moment such a layer holds a real card number or a real inbox password, it has stopped being a piece of software sitting beside the user's own access and has become a custodian of it, with the compliance and liability obligations that come with the word. The sensible way to build this is on top of existing card issuers and identity providers — not by reinventing them — so that the layer's real job stays what it should be: evaluating every proposed action against a user's stated rules, deterministically, every time. Building a bank is somebody else's business. Getting the validation right is ours.

The practical payoff

None of this requires trusting an agent more. It requires trusting it less, in a specific and useful sense: give it exactly the access a given task needs, state the rules once instead of hoping they are inferred correctly, and let a deterministic layer — not the agent's own judgment — be the thing standing between a request and a $200 mistake. That is a less exciting story than a smarter model, and we think it is the one that will actually hold up as these agents move from novelty to default interface for how people spend money and manage their lives.

About Predictika

Predictika.ai builds a patented constraint-based configuration and pricing engine rooted in a research lineage that runs from Xerox PARC through Selectica, the enterprise CPQ pioneer whose customers included IBM, Cisco, Dell, GE, Hitachi, Disney, and AT&T. Predictika's declarative modeling language, LVML, carries forward a distinctive prototype object-oriented architecture in which sub-entities inherit both parameters and constraints from the structures that contain them — a direct technical descendant of that PARC lineage. The company holds patents covering deterministic validation of LLM-driven systems (U.S. 11,544,475 and 11,914,970).

About the author

Dr. Sanjay Mittal is the founder and CEO of Predictika and the architect of its constraint-based reasoning engine. He began his career as a research scientist at Xerox PARC (1982–1990), with pioneering work in artificial intelligence and constraint reasoning. He went on to found Selectica, which defined enterprise sales configuration (CPQ) for large organizations, building it from inception to a $5 billion IPO in 2000 and serving customers such as IBM, Cisco, Dell, GE, Hitachi, Disney, AT&T, and Reliance. Dr. Mittal was the inventor of Selectica’s industry-leading configuration engine and holds six patents from that work. At Predictika he has carried the constraint-based approach into the era of large language models, with further patents — including U.S. Patents 11,544,475 and 11,914,970 — covering the deterministic validation of AI-driven systems. He holds a B.Tech. from IIT Kanpur and a Ph.D. from Ohio State University.

Suggested Further reading

Syntactically Valid, Semantically Wrong: A Constraint-Based Approach to Safe AI-Agent Execution

Guiding AI Agents to Reason Correctly

ExecGuard: Execution Integrity for Enterprise AI Agents