docs: Fixing some typos

docs/cli/scanning-overview.mdx

@@ -155,7 +155,7 @@ entropy = 3.5
 
 # Keywords are used for pre-regex check filtering.
 # If rule has keywords but the text fragment being scanned doesn't have at least one of it's keywords, it will be skipped for processing further.
-# Ideally these values should either be part of the idenitifer or unique strings specific to the rule's regex
+# Ideally these values should either be part of the identifier or unique strings specific to the rule's regex
 # (introduced in v8.6.0)
 keywords = [
 	"auth",

docs/documentation/platform/audit-logs.mdx

@@ -22,6 +22,6 @@ Each log contains the following data:
 
 - Event: The underlying action such as create, list, read, update, or delete secret(s).
 - Actor: The entity responsible for performing or causing the event; this can be a user or service.
-- Timestamp: The date and time at which point the event occured.
+- Timestamp: The date and time at which point the event occurred.
 - Source (User agent + IP): The software (user agent) and network address (IP) from which the event was initiated.
 - Metadata: Additional data to provide context for each event. For example, this could be the path at which a secret was fetched from etc.

docs/documentation/platform/token.mdx

@@ -54,7 +54,7 @@ of the `/common` path within the development environment of the project; the tok
   There are a few reasons for why this might happen:
 
   - The service token has expired.
-  - The service token is insufficently permissioned to interact with the secrets in the given environment and path.
+  - The service token is insufficiently permissioned to interact with the secrets in the given environment and path.
   - You are attempting to access a `/raw` secrets endpoint that requires your project to disable E2EE.
   - (If using ST V3) The service token has not been activated yet.
   - (If using ST V3) The service token is being used from an untrusted IP.

docs/integrations/cicd/jenkins.mdx

@@ -1,6 +1,6 @@
 ---
 title: "Jenkins"
-description: "How to effective and securely manage secrets in Jenkins using Infisical"
+description: "How to effectively and securely manage secrets in Jenkins using Infisical"
 ---
 
 Prerequisites:

docs/internals/overview.mdx

@@ -32,6 +32,6 @@ This section covers the internals of Infisical including its technical underpinn
     icon="ticket"
     color="#3775a9"
   >
-    Learn best practices for utilizing Infisical sevrice tokens
+    Learn best practices for utilizing Infisical service tokens
   </Card>
 </CardGroup>

docs/internals/security.mdx

@@ -60,7 +60,7 @@ This token category is used by users and included in requests made from the Infi
 
 Each token is authenticated against the API and mapped to an existing user in Infisical. If no existing user is found for the token, the request is rejected by the API. Each token assumes the permission set of the user that it is mapped to. For example, if a user corresponding to a token is not allowed access to a certain organization or project, then the token is also not be valid for any requests concerning those specific resources.
 
-In the event of compromise, an attacker could use the token to impersonate the associated user and perform actions within the permission set of that user. While they could retrieve secrets for a project that the user is part of, they could not, however, decrypt secrets if the project follows Infisical's default zero-knowlege architecture. In any case, it would be critical for the user to invalidate this token and change their password immediately to prevent further unintended actions and consequences.
+In the event of compromise, an attacker could use the token to impersonate the associated user and perform actions within the permission set of that user. While they could retrieve secrets for a project that the user is part of, they could not, however, decrypt secrets if the project follows Infisical's default zero-knowledge architecture. In any case, it would be critical for the user to invalidate this token and change their password immediately to prevent further unintended actions and consequences.
 
 ### Service token
 
@@ -103,7 +103,7 @@ If using [Infisical Cloud](https://app.infisical.com), snapshots of MongoDB data
 
 ### Offline usage
 
-Many teams and organizations use the [Infisical CLI](https://infisical.com/docs/cli/overview) to fetch and inject secrets back from Infisical into their applications and infrastructure locally; the CLI has offline fallback capabiltiies.
+Many teams and organizations use the [Infisical CLI](https://infisical.com/docs/cli/overview) to fetch and inject secrets back from Infisical into their applications and infrastructure locally; the CLI has offline fallback capabilities.
 
 If you have previously retrieved secrets for a specific project and environment, the `run/secret` command will utilize the saved secrets, even when offline, on subsequent fetch attempts to ensure that you always have access to secrets.
 
@@ -141,7 +141,7 @@ For example, you can define a role provisioning access to secrets in a specific
 
 ### Audit logging
 
-Infisical's audit logging feature spans 25+ events, tracking everything from permissioning changes to queries and mutations applied to secrets, for security and compliance teams at enterprises to monitor information access in the event of any suspicious activity or incident review. Every event is timestamped and information about actor, source (i.e. IP address, user-agent, etc.), and relevant metadata is included.
+Infisical's audit logging feature spans 25+ events, tracking everything from permission changes to queries and mutations applied to secrets, for security and compliance teams at enterprises to monitor information access in the event of any suspicious activity or incident review. Every event is timestamped and information about actor, source (i.e. IP address, user-agent, etc.), and relevant metadata is included.
 
 ### IP allowlisting
 
@@ -162,7 +162,7 @@ Please email security@infisical.com to request any reports including a letter of
 Whether or not Infisical or your employees can access data in the Infisical instance and/or storage backend depends on many factors how you use Infisical:
 
 - Infisical Self-Hosted: Self-hosting Infisical is common amongst organizations that prefer to keep data on their own infrastructure usually to adhere to strict regulatory and compliance requirements. In this option, organizations retain full control over their data and therefore govern the data access policy of their Infisical instance and storage backend.
-- Infisical Cloud: Using Infisical's managed service, [Infisical Cloud](https://app.infisical.com) means delegating data oversight and management to Infisical.  Under our policy controls, employees are only granted access to parts of infrastructure according to principle of least privilege; this is especially relevent to customer data can only be accessed currently by executive management of Infisical. Moreover, any changes to sensitive customer data is prohibited without explicit customer approval.
+- Infisical Cloud: Using Infisical's managed service, [Infisical Cloud](https://app.infisical.com) means delegating data oversight and management to Infisical.  Under our policy controls, employees are only granted access to parts of infrastructure according to principle of least privilege; this is especially relevant to customer data can only be accessed currently by executive management of Infisical. Moreover, any changes to sensitive customer data is prohibited without explicit customer approval.
 
 It should be noted that, even on Infisical Cloud, it is physically impossible for employees of Infisical to view the values of secrets if users have not explicitly granted Infisical access to their project (i.e. opted out of zero-knowledge).