An agent is a new type of privileged account
CyberArk introduced a solution for AI-agent identities in November 2025. Unlike an ordinary assistant, an agent can access company data, call APIs and alter another system. When it uses a shared service account or long-lived key, an organisation cannot reliably determine who initiated an action or whether it was authorised. The product treats each agent as a distinct non-human identity with its own lifecycle and policy.
An agent may dynamically create worker instances and attach new tools, so static account lists quickly become outdated. Businesses need automatic discovery, an assigned owner and revocation after the task ends. Development and production identities must also remain separate even when they use the same model.
Short-lived permission limits the consequences of an error
Traditional service accounts can retain passwords or tokens for years. The modern model issues credentials only for a specific action and lets them expire afterwards. CyberArk uses privileged-access management and secret storage so an agent need not know or place a password in its prompt. A policy layer checks identity, purpose and rules before brokering access.
Expiry alone is insufficient: the scope must match the task and credentials must not be passed to another process. A financial agent may read an approved invoice, while changing a supplier's bank account should require separate permission and human approval. The goal is to ensure that a single model or tool error cannot expose the whole environment.
Identity must preserve the origin of human intent
The audit trail should link an agent's action to the user, application and original request. Merely recording a service-account name cannot show whether the agent followed a routine process or reacted to a malicious document. Delegation should preserve the chain of responsibility while avoiding unnecessary sensitive content.
When one agent calls another, full permissions must not be inherited automatically. The subordinate should receive only what its part of the task requires. CyberArk is entering an emerging field in which identity policy is combined with agent-workflow context, and success will depend on integrations with frameworks and clouds.
Machine identities already outnumber human ones
Companies have long managed certificates, API keys, workload identities and service accounts. AI agents do not create the problem from scratch, but make it far more dynamic: an experimental agent can be created in minutes and connected to a database. CyberArk's use of established privileged-access disciplines is therefore more credible than a separate AI silo.
Customers should verify coverage of creation, approval, secret rotation, role changes, monitoring and retirement across Kubernetes, clouds, SaaS and private APIs. A unified policy helps, but also makes the identity platform itself a critical control layer whose availability and protection matter.
The Palo Alto Networks acquisition changes the commercial setting
CyberArk became part of Palo Alto Networks when the acquisition closed in February 2026. Agent identity can now be linked with a broader cloud, network and monitoring platform,for example, suspicious behaviour could revoke an identity and block related traffic. Customers should also watch whether a formerly neutral identity layer becomes too closely tied to one ecosystem.
A large acquisition brings resources and distribution, but may change pricing, licensing and priorities. Users should seek clear plans for support, interfaces and audit-data export. Open standards and capable APIs are commercial requirements because agent security must span many vendors.
The first deployment should start with one sensitive path
An organisation can pilot one process with a clear result, such as reading service tickets and creating a change request. It should map identities, tools and secrets, enable temporary access and verify the audit trail. Useful measures include excess permissions, immediate revocation and trace completeness, not just speed.
For Czech businesses, local-application integration, European data processing and qualified partners will matter. The underlying rule remains conservative: software should not receive permanent access merely because it appears intelligent. The benefit is proven when every machine action can be attributed, limited and safely stopped.
Sources and editorial note
The Jews.cz editorial team prepared this article from the public materials listed below. Company or institutional claims are distinguished from independently documented facts and editorial interpretation.
