Short answer: Yes, and no. In AgentAdmit a grant can carry two short statements: the app’s declared purpose, written by the app owner, and the user’s intent, typed by the user in their own words on the consent page. Neither one is enforced. Every verification decision is made on scopes, connection status, and consent. The two statements go on record instead: they ride every audit row, the grant event, every alert, and, for the user’s words, the passkey-signed commitment, so a human reviewing the trail later can judge whether the agent’s behavior still matches what was said.
What is a declared purpose on an agent grant?
A declared purpose is the app’s one-line reason the grant exists, up to 300 characters, set by the app’s backend when it opens a consent session. The user sees it on the hosted consent page before approving anything, under the label “Declared purpose”. TrainerTracer, the first production integration, declares “Connect an AI agent to TrainerTracer with only the permissions you approve.”
Once the user approves, the purpose is stored on the connection. It comes back to the app on every successful verification call. It is stamped into every per-call audit row, including refused calls. It is written into the grant event when the connection is created and again when it is revoked. When an alert fires, the purpose travels with it in the webhook payload and the email.
None of that changes what the agent may do. The scope list does that. Purpose answers a different question, months later: what was this connection for?
Why record the user’s own words as well?
Because the app’s words and the user’s words are not the same thing, and the user’s are the ones that matter in a dispute. The consent page has an optional field titled “Your Intent”. The prompt under it reads: “What do you want this agent to do for you? Your own words go on record with the grant, separate from the app’s declared purpose above.” A user might type “build me a weekly workout summary” under an app purpose that talks about connecting an agent in general.
User intent flows exactly like purpose: stored on the connection, returned on verification, stamped into audit rows, carried on grant and revocation events, included in alert payloads. When the consent page runs a presence ceremony, the intent text is part of the commitment the passkey signs, alongside the scopes, duration, and declared purpose. The difference is whose words they are: the authenticator signs what the user said they wanted, not only what the app declared. If the user edits the text after the ceremony, the page requires a fresh one, because the earlier signature covered different words.
The two fields are never merged. Purpose is app-declared. Intent is user-declared. An export shows both, side by side, on the same row.
Is the purpose or intent enforced at verification time?
No, by design. A verification decision reads the scopes on the grant, whether the connection is active, and the consent state. It never reads purpose text or intent text. If an agent with a read-workouts scope calls the read-workouts endpoint, the call is allowed whether the stated intent was a weekly summary or anything else.
That is deliberate. Enforcing a sentence of text would mean a machine deciding whether “summarize my week” covers a particular call. That judgment belongs to a person, and it belongs at review time, with the evidence in front of them. Scopes, durations, call ceilings, and confirm-each-time are the enforcement tools. Purpose and intent are the record that makes the review honest.
What does the review actually look like?
Three places, all fed by the same two fields.
The first is the trail itself. The per-call audit export and the consent-ledger export both carry purpose and intent on every relevant row, so a question like “was this agent doing what the user asked for in July?” is answered from the export, not from memory.
The second is the alert. AgentAdmit watches each connection for drift from its own established pattern: a historically narrow connection suddenly using most of its granted scopes in one window, a scope that sat unused for two weeks waking up, or call frequency several times the prior daily average. These boundary-deviation alerts are review-only. They are always warnings, they never revoke anything, and the kill switch cannot be enabled for them. Each one delivers the drift evidence next to the declared purpose and the user’s intent, so the person reading it judges whether the behavior still matches the words. The text is never parsed or scored by the system.
The third is the revocation screen. When a user comes back to a connection weeks later, the dashboard shows the purpose under the connection and the intent they typed. “Is this still appropriate?” gets answered against their own stated boundary, not only the app’s.
Where does this show up for the user and the app owner?
For the user: on the consent page before approval, on the existing-grant review step that lists each active grant’s agent, scopes, and declared purpose before a new one can be created, and on their connection list afterward.
For the app owner: in the dashboard’s connection rows and Logs page, in the two exports, and in every alert delivery. Apps using the React components get purpose on the connections list without extra code. Server SDKs return purpose and intent on the verification result.
Shipped in August 2026: declared purpose first, user intent a week later, both live for every app on every plan, including test keys.
FAQ: declared purpose and user intent on agent grants
Can the agent change the purpose or intent after the grant?
No. Both are set at consent time and stored on the connection. An agent holds a token, not a way to edit the grant record. A new purpose means a new grant, which the user sees and approves.
What if the app leaves purpose empty?
The field is optional. The grant works the same and the audit rows simply carry no purpose. We recommend setting it, because a blank reason is the weakest possible answer to “what was this for?” in a later review.
Does an alert on drift mean the agent misbehaved?
No. It means the connection’s pattern changed relative to its own history. The alert puts the evidence next to the recorded purpose and intent and leaves the judgment to a person. It never revokes on its own.
Is the user’s intent cryptographically bound to anything?
When a presence ceremony runs, the intent text is part of the commitment the user’s passkey signs, alongside the scopes, duration, and purpose. An auditor can recompute that commitment from the record and check it against the signed response. That proves a user-verified ceremony signed those exact words. It does not prove the user read the screen.
Why not just enforce intent with a model?
Because a model’s guess about whether a call matches a sentence is not something to build an authorization decision on. Enforcement stays deterministic: scope, status, consent, ceilings, confirmation. The sentence stays on record for the human.
Declared purpose and user intent are live on every AgentAdmit grant. The App Owner Guide and the MCP Server Operator Guide show where each field is set. See how the consent page records both at agentadmit.com.