AI Agents Need Access to Business Systems. How Do We Keep Credentials Secure?

An agent reaches the sign-in screen for your CRM and asks for a password. Pasting it into a prompt may look like the quickest way to finish the job, but it creates another copy of a powerful secret. The better question is whether the agent can use an approved sign-in mechanism without receiving the password itself, and what it will be able to do once logged in.

This article focuses on that credential hand-off. Our existing AI-agent identity and access guide covers the broader governance problem. Securely delivering a credential is a distinct control; it does not, by itself, define the authority of the resulting session.

What 1Password announced

In its 22 October 2026 1Password for Agents announcement, 1Password describes supported agents requesting a credential from a user's vault. The user reviews and approves the request, and 1Password fills it into the destination website without exposing the password or one-time code to the agent. These are the vendor's stated capabilities, not an independent Altitude product test.

The availability limits matter. The announcement says the platform is currently available for Individual and Family accounts on 1Password.com, not accounts on 1Password.eu or 1Password.ca. Some integrations are available and others are coming soon; platforms and safeguards vary by partner. This should not be presented as a generally available enterprise control for every agent or every business plan. Confirm your account region, subscription and exact integration before planning adoption.

Why copying credentials is the wrong shortcut

Passwords pasted into prompts can enter conversation histories, diagnostic records or connected tools. Shared accounts obscure responsibility. Unmanaged API keys in scripts or notes can remain valid long after the original experiment ends. An employee leaving the business may not automatically end an agent's persistent session.

A password vault can reduce uncontrolled copying and centralise secret management. It cannot make an overprivileged account safe merely by protecting its password. An agent that cannot read the secret may still be able to view confidential records, export data or send messages through an authenticated session. Treat that session as valuable access in its own right.

Choose the identity model before choosing the secret

A human account represents a person. A service account represents an operational purpose. An application identity lets software authenticate as itself. Delegated access lets an application act on behalf of a signed-in user, within the permissions and restrictions of that system. Machine-to-machine authentication can operate without a human signing in for each action.

Use the supported model that fits the task, rather than giving every agent a normal licensed Microsoft 365 user account. Some tasks need no reusable password at all. Others may require a tightly scoped service identity, a certificate or a short-lived token. Record the owner, purpose, permission scope, credential location and recovery procedure.

Separate approval to sign in from approval to act

Before approving a vault request, verify the destination, selected account and business purpose. Use a dedicated, minimally privileged account where the platform supports it. After sign-in, enforce restrictions in the target application: an agent helping draft an email should not automatically be allowed to delete mailboxes or change payment records.

Apply Zero Trust principles to each connection. Require explicit access approval, constrain sessions, protect stored secrets and record activity. Give tokens suitable expiry periods and rotate credentials when appropriate. Do not assume that disconnecting the vault integration immediately logs the agent out of every website it already accessed.

Build an offboarding procedure that covers the agent platform, vault connection, target application, refresh tokens and active sessions. Test the supported revocation mechanisms with a non-production account. Verify both that a fresh sign-in fails and that previously established access ends as expected; different services handle this differently.

Microsoft 365 and Entra ID need permission review

For Microsoft 365 integrations, inspect app registrations, service principals, consent and granted permissions in Entra ID. Microsoft distinguishes delegated permissions from application permissions: delegated access involves a signed-in user, while app-only access can run without one. Broad application permissions can expose substantial tenant data.

Check whether narrower resource access is supported for the actual task. Human administrator MFA remains important, but does not impose human approval on every app-only API request. Logging, sign-in policies and other controls depend on the integration and licensing; verify coverage instead of assuming a familiar product name provides it.

Evidence to request before deployment

• A supported-integration and availability check, including account region and plan.
• A demonstration of the credential flow using synthetic data and a test account.
• The exact target-system permissions and who approves changes.
• Records linking sign-ins and actions to an agent and accountable owner.
• A tested method for ending sessions, revoking tokens and removing unused access.

Altitude IT can review the technical identity and access implications through an independent review. Workflow opportunities and wider adoption can be explored separately with Altitude AI. Protecting an agent's credentials matters; controlling its business authority is equally important.

Primary sources

1Password announcement and availability conditions; Microsoft permissions and consent guidance. Checked 2 November 2026; product availability may change.