AI is changing both sides of the security equation: it's making software easier to build and attacks easier to carry out.
At Privy, defense in depth has always been central to how we build. As the threat landscape evolves, so does our approach to security.
Agentic tools are lowering the skill floor for attackers. Work that once required specialized knowledge and significant manual effort, such as finding weaknesses or adapting an exploit, can increasingly be automated. Attackers can try more approaches, move faster, and carry out attacks that would previously have been beyond their reach.
At the same time, those tools are helping developers ship much more code. That creates more opportunities for vulnerabilities to enter production, and more software that needs to be understood, tested, and secured. The pace of development is changing faster than traditional security review can keep up.
Recent reports of security incidents involving Binance and Polymarket are a reminder of the stakes across the industry. For wallets, security has always meant protecting more than private keys. It means securing the software, credentials, dependencies, and people that can influence the movement of money, including the agents increasingly acting on a user’s behalf.
Security cannot depend solely on catching problems before code ships. It also needs to constrain what systems can do and limit the impact when something goes wrong.
Here’s how the risks are changing and how we’re building on that foundation.
How AI is changing the security landscape
Many of these security risks aren't new, but AI is making them harder to manage. Five areas stand out.
1. Working code isn't necessarily secure code
AI-generated code can meet a functional requirement while missing the security constraints of the system it operates in. Authorization is a good example: implementing it correctly requires understanding who can access which resources, through which endpoints, and under what conditions, not just whether an individual function works. In a controlled 2025 evaluation, Veracode found that roughly 45% of tested code-generation tasks introduced a detectable security flaw.
2. Dependency growth can outpace security review
AI coding assistants can introduce third-party packages without developers deliberately evaluating them. Those packages can bring vulnerabilities of their own, including in the dependencies they pull in. As development accelerates, this dependency growth can outpace security review.
3. The AI development toolchain is an attack surface
AI coding assistants read repositories, documentation, and configuration files, some of which may contain attacker-controlled content. Malicious instructions embedded in a README or code comment can attempt to manipulate an assistant into generating unsafe code or exposing sensitive information.
When assistants are granted access to terminals, APIs, or internal systems, including through MCP servers, a malicious instruction can lead to actions in those systems, not just an unsafe code suggestion.
4. Attackers have access to the same tools
AI can accelerate vulnerability discovery, exploit development, and targeted phishing. An attacker can use it to analyze code for weaknesses, adapt an exploit to a particular target, or craft convincing phishing messages tailored to someone’s role and responsibilities.
Agentic workflows can connect these tasks into a repeatable process: identify a potential weakness, test an approach, and use the results to decide what to try next. This lowers the skill floor for less experienced attackers while giving sophisticated attackers more leverage. The threat isn’t just faster individual attacks, it’s the ability to pursue more targets and test more approaches with less manual effort.
5. Agents with financial permissions raise the stakes
The risks extend beyond how software is built to what agents can do once it is running. When agents can access sensitive data or move money, manipulating their behavior can have direct financial consequences. An attacker could hide instructions in an invoice, webpage, or external document to try to redirect an agent into exposing information or initiating an unauthorized transaction.
The defense cannot depend solely on an agent recognizing malicious instructions. Agents need narrowly scoped permissions and transaction controls enforced outside the model, so those limits still apply if the agent is manipulated.
Building on Privy’s security approach
Privy’s defense in depth approach combines protection for private keys with controls over how those keys can be used. Sensitive wallet operations take place inside secure enclaves, where configured policies are evaluated before signing. Developers can restrict permitted destinations and transaction amounts, while authorization quorums can require approval from multiple keys.
Protecting a key does not, by itself, prevent an application from requesting an unintended transaction. Transaction policies constrain what an authorized signer can do. Separating transaction-signing authority from policy-management authority helps ensure that compromising a signer does not also give an attacker permission to remove those constraints.
The same principle applies beyond wallets. We need safeguards for how software is developed, what dependencies it brings in, and what tools and systems can access. Independent security assessments, code reviews, and dependency monitoring remain important. We are building on that work with five priorities.
Bring security into the development workflow
Developers at Privy can submit a pull request, product requirements document, or technical spike for an automated security review. Our internal review harness evaluates these using context from Privy’s codebase, threat model, and security principles. This lets us assess proposed changes against the system they will operate in, rather than looking for common vulnerability patterns alone.
This brings security feedback earlier into the development process. Automated review supports that process, while security engineers remain responsible for investigating findings and making decisions that require deeper judgment.
Strengthen control over dependencies
We use GitHub tooling, Semgrep’s dependency analysis, and Socket to identify vulnerabilities and other risks in third-party packages. These checks complement application code review by examining both direct dependencies and the packages those dependencies pull in.
No scanner can guarantee that a package is safe. The goal is to make dependency risks visible and actionable as software changes, rather than treating a package as trusted indefinitely because it was accepted once.
We also apply a waiting period before adopting newly published package versions. This gives compromised releases more time to be identified before they enter our dependency tree.
Put boundaries around AI development tools
We build on Stripe’s shared AI tooling and add Privy-specific instructions and configuration in our repositories. Our agent instructions cover handling secrets, validating inputs, and testing changes that cross authentication and wallet boundaries.
We pair that guidance with tool-level controls. For example, our repository’s Claude Code configuration includes explicit command permissions and restrictions. Instructions help guide an assistant’s behavior, but they are not a security boundary on their own.
Monitor production and prepare for failures
Security work does not end when code ships. We use Datadog and other internal metrics to monitor production systems and investigate issues.
Our disaster-recovery work addresses a complementary question: how do we restore service when prevention and normal operations are not enough? Monitoring helps us understand a problem, incident response helps us address it, and recovery planning prepares us to restore operations.
Preserve expertise and measure effectiveness
Automation is only useful if we can evaluate its results and recognize where it falls short. Engineers still need to investigate novel threats, and we need to measure whether our controls actually reduce risk and improve response times. We review incidents weekly across all teams to identify patterns and opportunities to improve our systems and processes.
Security requires continuous investment
At Privy, our responsibility is to secure the infrastructure developers rely on to manage and move assets. But protecting wallets also requires securing the applications, credentials, and systems interacting with them. No single layer of infrastructure can address every potential vulnerability.
For developers building with Privy, our security checklist outlines practical steps to secure your integration.
As software becomes more autonomous, security can't depend on every line of code being reviewed or every agent behaving exactly as intended. We need to keep investing in controls that enforce security continuously, even when something else goes wrong.
Learn more about Privy's security architecture.
