Cookies and sessions

#How cookies and sessions work

A server sends Set-Cookie in a response. From then on, the browser sends a Cookie header with each request to that site. The server reads the cookie, finds the session it refers to, and treats the request as coming from the logged-in user.

Cookies carry attributes that control how the browser handles them:

#Why it matters for AI agents

Login state lives in cookies. A tool that sends the cookies acts as the user. That is useful when an agent reads your own account pages, and it is a risk when the tool is careless. Before you give any agent access to a logged-in session, check where its requests go and what it can change.

#Wield and cookies

Wield never copies or sends your cookies or passwords. Recipes run in a tab of the site you already use, so requests carry the session your browser already has. Recipes cannot set a Cookie or Host header. A recipe may read a named token that the site keeps for its own requests, and Wield redacts that value from results and logs.

#Related terms

• CSRF token
• Bearer token
• Same-origin policy
• Least privilege

#FAQ

#What are HttpOnly and SameSite?

HttpOnly tells the browser to keep the cookie away from page scripts, so code on the page cannot read it. SameSite tells the browser whether to send the cookie on requests that start on another site. Its values are Strict, Lax and None.

#Can an AI agent use my logged-in session safely?

Only if the tool keeps the session on your machine and limits what it does. Check three things: where the requests go, whether the tool asks before any write, and what it logs. Wield keeps credentials and browsing data on your device, sends requests only to the origins a recipe lists, and waits for your Allow before any write.