diff --git a/README.md b/README.md
index 6d306e69..9a5f2ef0 100644
--- a/README.md
+++ b/README.md
@@ -149,6 +149,10 @@ constructs:
 
 More constructs are coming soon! Got suggestions? [Open and upvote drafts](https://github.com/getlift/lift/discussions/categories/constructs).
 
+## Lift-specific configuration
+
+Lift default behaviors can be override and configured as per your likings using the `lift` property at the root of your `serverless.yml` file. This property is optional as well as all the [configurable options within](docs/configuration.md). Configurations specified at this level affect all constructs defined within the same service file.
+
 ## Ejecting
 
 You can eject from Lift at any time: Lift is based on CloudFormation. That allows anyone to kickstart a project with Lift, and fallback to CloudFormation if you ever grow out of it.
diff --git a/docs/configuration.md b/docs/configuration.md
new file mode 100644
index 00000000..bc21f379
--- /dev/null
+++ b/docs/configuration.md
@@ -0,0 +1,34 @@
+# Lift-specific configuration
+
+This documentation describes all available properties that can specified in the `lift` property at the root of your service file. All options defined here affect all the constructs defined in the same service file
+
+## Automatic permissions
+
+Each construct ships with a pre-defined list of IAM permissions that will be added to the IAM role used by all Lambda functions defined in the same service file and provisionned using the Serverless Framework capabilities. This is to ensure new-comers don't struggle with finding the correct permission sets to interact with the deployed constructs.
+
+For exemple, the [`storage` construct](storage.md) will happen the following permissions to the IAM role provisionned by the Serverless Framework and used by all Lambda functions within the same service file:
+
+- `s3:PutObject`
+- `s3:GetObject`
+- `s3:DeleteObject`
+- `s3:ListBucket`
+
+You can use the `automaticPermissions` options if you want to opt out of this default behavior. This can be especially useful for production environment where you want to provision fined-grained permissions based on your actual usage of the construct - i.e. you may want to only read from the bucket provisionned uisng the `storage` construct.
+
+Here is an exemple `serverless.yml` service file disabling automatic permission for a `storage` construct:
+
+```yaml
+service: my-app
+provider:
+  name: aws
+
+lift:
+    automaticPermissions: false
+
+constructs:
+    avatars:
+        type: storage
+
+plugins:
+    - serverless-lift
+```
diff --git a/docs/serverless-types.md b/docs/serverless-types.md
index 1cced8fa..1cda53b8 100644
--- a/docs/serverless-types.md
+++ b/docs/serverless-types.md
@@ -1,4 +1,4 @@
-# Lift TypeScript definitions
+# Lift-specific configuration
 
 While YAML remains the most popular declarative syntax for Serverless service file definition - a.k.a `serverless.yml` - you can also use Javascript/TypeScript definitions - i.e. `serverless.js` and `serverless.ts`. You can find more information on using JS/TS service file in the [Serverless official documentation](https://www.serverless.com/framework/docs/providers/aws/guide/intro#services).
 
@@ -15,6 +15,9 @@ const serverlessConfiguration: AWS & Lift = {
   service: 'myService',
   frameworkVersion: '2',
   plugins: ['serverless-lift'],
+  lift: {
+    automaticPermissions: false,
+  },
   constructs: {
     avatars: {
       type: 'storage',
diff --git a/src/plugin.ts b/src/plugin.ts
index e9182b8f..a601274e 100644
--- a/src/plugin.ts
+++ b/src/plugin.ts
@@ -496,10 +496,10 @@ class LiftPlugin {
     }
 }
 
-export type Lift = {
+export type Lift = Partial<{
     constructs: FromSchema<typeof CONSTRUCTS_DEFINITION>;
     lift: FromSchema<typeof LIFT_CONFIG_SCHEMA>;
-};
+}>;
 
 LiftPlugin.registerProviders(AwsProvider, StripeProvider);