Discovery Trending Launches KYC Verified Watchlist Risk Alerts
Token Minter AI Threat Detection Token Burner
Blog & News Docs Visit SolidProof.io

Agentify Info

www.agentifyai.org

Agentify empowers AI agents to interact, adapt, and automate Web3 tasks using the Model Context Protocol (MCP). From DeFi to cross-chain operations, deploy agents that evolve and monetize as they work.

Agentify Logo
Onboarded date 20/05/2025

Team and KYC Verification

The team has securely submitted their personal information to SolidProof.io for verification.

In the event of any fraudulent activities, this information will be promptly reported to the relevant authorities to ensure accountability and compliance.

TrustNet Score

The TrustNet Score evaluates crypto projects based on audit results, security, KYC verification, and social media presence. This score offers a quick, transparent view of a project's credibility, helping users make informed decisions in the Web3 space.

77.74
Poor Excellent

Real-Time Threat Detection

Real-time threat detection, powered by Cyvers.io, is currently not activated for this project.

This advanced feature provides continuous monitoring and instant alerts to safeguard your assets from potential security threats. Real-time detection enhances your project's security by proactively identifying and mitigating risks. For more information, click here.

Security Assessments

Select the audit
"Static Analysis Dynamic Analysis Symbolic Execution SWC Check Manual Review"
Contract address
N/A
Network N/A
License N/A
Compiler N/A
Type N/A
Language Solidity
Onboard date 2025/05/22
Revision date 2025/06/02

Summary and Final Words

No crucial issues found

The contract does not contain issues of high or medium criticality. This means that no known vulnerabilities were found in the source code.

Contract is upgradeable

The contract uses a proxy pattern or similar mechanism, enabling future upgrades. This can introduce risks if the upgrade mechanism is not securely managed.

Scope of Work

This audit encompasses the evaluation of the files listed below, each verified with a SHA-1 Hash. The team referenced above has provided the necessary files for assessment.

The auditing process consists of the following systematic steps:

  1. Specification Review: Analyze the provided specifications, documentation, and user flow descriptions to fully understand the web application's intended behavior, component structure, and data interactions.
  2. Manual Code Examination: Conduct a thorough manual review of the codebase (JavaScript/TypeScript) across frontend (e.g., React, Next.js, Vue) and backend components (e.g., Node.js, Express, FastAPI) to detect potential vulnerabilities, insecure coding patterns, and architectural inconsistencies.
  3. Specification Alignment: Ensure that the implementation of features, routes, and components aligns with the stated design intent and documented functionality.
  4. Test Coverage Assessment: Evaluate the existing test coverage (unit, integration, and E2E if applicable) and identify areas of logic that are untested or under-tested, especially security-critical components.
  5. Component & Flow Validation: Trace component interactions and control flows (e.g., data fetching hooks, auth tokens, session management) to uncover race conditions, leakage of sensitive data, or logic flaws in async handling.
  6. Security Best Practices Evaluation: Assess the web application against established security and performance best practices, including OWASP Top 10 for Web, secure storage, safe API integration, XSS/CSRF mitigation, and proper access control.
  7. Actionable Recommendations: Provide precise and actionable recommendations categorized by severity to guide remediation. Each issue is documented with a description, potential impact, and a proposed mitigation strategy.

A file with a different Hash has been intentionally or otherwise modified after the security review. A different Hash may indicate a changed condition or potential vulnerability that was not within the scope of this review.

Final Words

The following provides a concise summary of the audit report, accompanied by insightful comments from the auditor. This overview captures the key findings and observations, offering valuable context and clarity.

This security audit of the Agentify-AI frontend codebase assessed the React/Next.js application for security vulnerabilities, architectural flaws, and areas of improvement related to user experience, error handling, and maintainability. The focus was exclusively on the client-side application; no backend or smart contract code was within the scope of this assessment.

The codebase exhibits a modern component-driven architecture typical of Next.js applications, integrating wallet-based user authentication and AI-driven tooling. While the structure is generally modular and well-structured, the audit uncovered several issues of varying severity. Most issues have been successfully addressed, with only two remaining unresolved items requiring attention before production deployment.

Technical Summary
  • Incorrect User Context for Initial Agent Loading (CRITICAL-F001): The playground page (src/app/playground/page.tsx) still executes server-side without incorporating client-side authentication to obtain the actual user's ID. The API call to /api/v1/agents/list-agents/ does not include any user-specific identifier, creating a critical security vulnerability. STATUS: UNRESOLVED
  • Incorrect Fallback for Agent Search (HIGH-F001): The agent fetch logic in useChatHook.ts that defaulted to user_id: '1' when no wallet was detected has been remediated. STATUS: RESOLVED
  • Missing User-Facing Error Feedback (MEDIUM-F001): Significant improvements have been made with CommandInterface.tsx and Dashboard.tsx now providing user-facing error feedback via AI messages and toast notifications. However, some hooks in Dashboard.tsx still need systematic error handling to avoid indefinite loading states. STATUS: PARTIALLY RESOLVED
  • Hardcoded Timezone Conversion (LOW-F001): The function convertToISTDate in Dashboard.tsx that forced all dates into the 'Asia/Kolkata' timezone has been updated to support user-configurable or local timezone handling. STATUS: RESOLVED
  • Excessive Console Logging (LOW-F002): Console logs have been stripped from production builds to reduce noise and potential information leakage. STATUS: RESOLVED
  • Use of TypeScript 'any' Type (LOW-F003): While some improvements have been made in function parameters and state variables, significant concerns remain with data fetched via response.json() and AI response handling, which continue to use implicit any types without proper interface validation. STATUS: PARTIALLY RESOLVED
  • Hardcoded Agent Icons (LOW-F004): The manual icon assignment in AgentSelector.tsx has been refactored to use data-driven icon metadata from the backend. STATUS: RESOLVED
  • Client-Side Trust in AI Parameters (INFO-F001): Enhanced transaction parameter display and user verification processes have been implemented in CommandInterface.tsx for improved user awareness and safety. STATUS: RESOLVED
Remediation Priority Summary
  1. Fix remaining user context handling: Convert playground page to client component to properly fetch agents using authenticated user identity (CRITICAL - UNRESOLVED).
  2. Complete error reporting improvements: Implement systematic error handling for remaining Dashboard.tsx hooks to prevent indefinite loading states (MEDIUM - PARTIALLY RESOLVED).
  3. Enhance TypeScript type safety: Address remaining any type usage in API response handling and AI message processing (LOW - PARTIALLY RESOLVED).
  4. Maintain security UX standards: Continue monitoring AI-powered transaction flows for proper parameter validation and user verification.

Note: This audit applies only to the frontend stack (Next.js/React). The backend (FastAPI) was reviewed separately. All issues identified here pertain to client-side logic, presentation, and user interaction with external services such as wallets and AI tools. No backend APIs or smart contracts were modified or directly assessed as part of this frontend audit.

Files and details

Findings and Audit result

Critical
High
1
Medium
1
Low
Optimization
1
Informational
high Issues | 1 findings

Resolved

#1 high Issue
Incorrect User Fallback for Agent Search
src/hooks/useChatHook.ts
LN/A (function fetchAgents)
Description

Defaulting to user_id: '1' if wallet address is unavailable can lead to incorrect agent data or errors.

Comments

In fetchAgents, remove the fallback to user_id: '1' when wallet address is not available. The function should require a valid user context or fail gracefully.

medium Issues | 1 findings

Acknowledged

#1 medium Issue
Potential for Unhandled Errors / Lack of User-Facing Error Feedback
Various files (e.g., Dashboard.tsx, CommandInterface.tsx)
LN/A
Description

The UI does not always provide specific feedback when API calls or operations fail, sometimes relying on console logs or generic messages.

Comments

Systematically review UI components to ensure that error states from hooks are used to display clear, user-facing error messages.

Alleviation

Significant improvements have been made. CommandInterface.tsx now provides user-facing error feedback for many operations, typically as AI messages within the chat or via toast notifications (e.g., for history fetching, chat action errors, transaction failures with specific reasons). Dashboard.tsx also uses toasts for errors in several data fetching hooks (useFetchGasDetails, useFetchAgentChart, useFetchSavedCommands, useFetchLastCommand). However, for some hooks in Dashboard.tsx (e.g., useFetchDashboardHeader, useFetchChainActivity, and useFetchTransactions), while loading states are handled with skeletons, the error states returned by these hooks are not always explicitly used to display a distinct user-facing error message (like a toast or an error message within the component). An error might result in an indefinite loading skeleton or an empty state, which doesn't clearly differentiate between "no data" and "an error occurred". A more systematic use of the error prop from all data fetching hooks in the dashboard to show clear error messages would fully address this. LOW

low Issues | 4 findings

Resolved

#1 low Issue
Hardcoded Timezone Conversion
src/Components/NewDesign/Dashboard/Dashboard.tsx
LN/A (function convertToISTDate)
Description

Hardcoding timezone to IST might not be suitable for all users.

Comments

Dates are converted to 'Asia/Kolkata' timezone. Display dates in the user's local timezone or provide a timezone preference.

Resolved

#2 low Issue
Excessive Console Logs
Various files
LN/A
Description

Extensive use of console.log for debugging should be removed in production.

Comments

Remove numerous console.log statements from production builds.

Acknowledged

#3 low Issue
Use of 'any' Type
Various files (e.g., src/hooks/useFetchDashboardHeader.ts)
LN/A
Description

Use of 'any' type reduces TypeScript's benefits.

Comments

Replace 'any' with specific TypeScript interfaces/types for API responses and state variables to improve type safety.

Alleviation

Some areas demonstrate good type usage (e.g., function parameters, state variables, typed array elements in callbacks). However, a significant area of concern remains with data fetched via response.json(). These responses are often not immediately cast to or validated against specific interfaces, leading to implicit any types. For example, in CommandInterface.tsx, the toolMessage object parsed from an AI response is treated as any, and its properties are accessed without strong type guarantees. Similarly, data returned from custom hooks in Dashboard.tsx or within useChatHook.ts might effectively be any if the hooks themselves or the fetch().json() calls within them don't enforce strong typing on the results. This continues to be an area where type safety could be substantially improved.

Resolved

#4 low Issue
Hardcoded Agent Icons
src/Components/NewDesign/playground/AgentSelector.tsx
LN/A
Description

Hardcoding icons based on agentId makes it harder to add new agents with different icons without frontend code changes.

Comments

Agent icons are hardcoded based on agentId. Make icons data-driven by including icon information in the agent data from the backend.

informational Issues | 2 findings

Resolved

#1 informational Issue
Client-Side Trust of AI Tool Response Parameters
src/Components/NewDesign/playground/CommandInterface.tsx
LN/A (handleChat function)
Description

The frontend uses parameters from AI tool_response for transactions. While balance checks exist, this relies on AI & SDK security, and user wallet verification. This is an architectural aspect of AI agent systems.

Comments

Ensure wallet interaction clearly displays all critical transaction parameters for user verification. Consider additional client-side sanity checks on parameters received from AI tool responses if feasible.

Acknowledged

#2 informational Issue
Incorrect User Context for Initial Agent Loading
src/app/playground/page.tsx
LN/A (function fetchInitialAgents)
Description

Initial agent list in the playground is fetched for 'demo_user', which is a critical flaw if agent lists are user-specific or require authentication.

Comments

Modify src/app/playground/page.tsx to fetch initial agents using the actual authenticated user's ID, not 'demo_user'. This likely requires making it a client component to use Privy/Wagmi hooks.

Alleviation

The fetchInitialAgents function in src/app/playground/page.tsx still executes on the server-side without incorporating client-side authentication (Privy/Wagmi hooks) to obtain the actual user's ID. The API call to /api/v1/agents/list-agents/ does not include any user-specific identifier. If the backend requires user context for agent listing or defaults to a generic user, the vulnerability persists. The recommendation to convert this to a client component to fetch agents under the authenticated user's context has not been implemented.